Partners are required to pass an internal Tyro certification process so that we can check that the Tap to Pay app pairing or Tap to Pay SDK has been implemented as expected. This helps ensure that merchants and customers are provided with the best user experience possible.
If you are implementing the Tap to Pay SDK, your app embedding the SDK will also need to undergo a separate MPoC PCI certification process. Tyro can provide further details and assist you with this process.
Before you start, see Testing for sandbox environments, test cards and the sandbox testing tools.
Applicability is listed per integration path. NA means the test doesn't apply to that path.
| Test ID | Category | Test case | Testing steps | App — POS app pairing | App — WebPOS pairing | SDK | Partner verifies in sandbox |
|---|---|---|---|---|---|---|---|
| AF-1 | Authorisation flow | User must login to authenticate for POS Portal | • User required to authenticate before using POS Portal • When Authenticated, user has access to POS Portal • When not Authenticated, user has restricted access to POS Portal • Partner could send video/screen shot evidence of the above | Yes | Yes | Yes | No — verified by Tyro in production |
| AF-2 | Authorisation flow | Has option to authorise POS | • There is an option to Authorise POS for Embedded Payments found through the UI • Confirm flow exists • Mentions that user will be redirected to Tyro to complete authorisation • Partner could send video/screen shot evidence of the above | Yes | Yes | Yes | No — verified by Tyro in production |
| AF-3 | Authorisation flow | Integrates with Tyro Integration Portal | • Check that once the Authorise POS for Embedded Payments flow has been kicked off by opening the Tyro Integration Portal in a new tab • Check the url contains the POS ID and POS Reference as a query param. The POS ID will be their Client Id. e.g. https://integrate.stg.tyro.com/tap-to-pay?posId=client_id&posReference=pos_reference • Partner could send video evidence of the above | Yes | Yes | Yes | No — verified by Tyro in production |
| AF-4 | Authorisation flow | Authorising POS and Merchant ID on Tyro Integration Portal updates list of enabled Tap to Pay Locations | • Displays the correct list of MIDs that are owned by the current Merchant and allow user selection • Displays the correct list of authorised locations for Tap to Pay • Check what was enabled on the Tyro Integration Portal reflects this list • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-5 | Authorisation flow | Admin merchant can manage their Embedded Payments trading locations | • Partner to send screen shots or video that show the following: • How authorised locations are being shown • That there is ability to manage these locations • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-6 | Authorisation flow | Admin merchant can choose to use a MID and manage their Embedded Payments trading locations | • After completing the process on Tyro Merchant Portal, user navigates back to POS Portal • Merchant can choose a MID to use from a list of MIDs that is owned by the user • Merchant can see locations they are enabled for the chosen MID for Embedded Payments on POS Portal • Their Locations are listed • Shows list of authorised locations • Management options present for each location e.g. user access • Can Update Authorisation for each location • Redirect back to Tyro Integration Portal to complete • Deauthorised Locations not shown in authorised locations list • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-7 | Authorisation flow | Admin merchant can manage their Embedded Payments users and devices (sandbox) | • Partner to send screen shots or video that show the following: • How Admin users can manage devices • How Admin users can create Readers and 1 per device • How Admin users can disable users • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-8 | Authorisation flow | Admin merchant can manage their Embedded Payments users and devices | • Can manage Devices • Can create Reader • Single Reader per device • Can deauthorise Merchant ID • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-9 | Authorisation flow | Only one Reader is used per Device | • Check to see that this is happening through the device management process • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| AF-10 | Authorisation flow | Deauthorise POS and Merchant ID on Tyro Integration Portal updates list of enabled Embedded Payments Locations | • Displays the correct list of MIDs that are owned by the current Merchant • Displays the correct list of enabled locations for Embedded Payment • Check what was disabled on the Tyro Integration Portal reflects this list • Partner could send video evidence of the above | NA — handled within the Tap to Pay app | NA — handled within the Tap to Pay app | Yes | No — verified by Tyro in production |
| PA-1 | POS app | User must authenticate in App to use Tap to Pay | • User required to authenticate before using POS App • When Authenticated, user has access to POS App • When not Authenticated, user has restricted access to POS App • Tyro to test | Yes | Yes | Yes | Yes |
| PA-1A | POS app | Pairing | • Launch the Tap to Pay app from your POS for pairing • Make sure you can login and finish the pairing flow • The app closes on pressing finish • Opening the Tap to Pay app now shows the app's home screen | Yes | Yes | NA | Yes |
| PA-2 | POS app | App should not be able to purchase with a 0 amount | • No ability to start Embedded Payments transaction (purchase) with a 0 dollar amount • Tyro to test | Yes | Yes | Yes | Yes |
| PA-3 | POS app | App should not be able to refund a 0 amount | • No ability to start Embedded Payments transaction (refund) with a 0 dollar amount • Tyro to test | NA — refund capability not supported in current app release | NA — refund capability not supported in current app release | Yes | Yes |
| PA-4 | POS app | App should set the Order id as the transaction reference | • Tyro to check logs/postman that the orderID is being set as the transaction reference • Tyro to check logs/postman that the reference being sent is unique • Confirm between Partner and Tyro that these are matching up • Partner to confirm they are giving us a unique reference • Partner could send video evidence of the above | Yes | Yes | Yes | Yes |
| PA-5 | POS app | App should display the amount customer paid including surcharges applied | Prerequisite: Surcharging enabled for test MID on Tyro's side • Tyro to check final amount paid after processing a transaction includes surcharge | NA from 1 October 2026 | NA from 1 October 2026 | NA from 1 October 2026 | Yes |
| PA-6 | POS app | App should record the total amount plus the final surcharge if one was added | Prerequisite: Surcharging enabled for test MID on Tyro's side • Partner to provide evidence they are recording the total amount paid including surcharges applied | NA from 1 October 2026 | NA from 1 October 2026 | NA from 1 October 2026 | Yes |
| PA-7 | POS app | App should refund total amount plus any surcharges applied | Prerequisite: Surcharging enabled for test MID on Tyro's side • Tyro to check when performing a refund for a transaction with a surcharge applied, that total amount includes the surcharge amount | NA from 1 October 2026 | NA from 1 October 2026 | NA from 1 October 2026 | Yes |
| PA-8 | POS app | Surcharge added to POS tax invoice | Prerequisite: Surcharging enabled for test MID on Tyro's side • Partner to provide evidence that surcharge has been added to the tax invoice | NA from 1 October 2026 | NA from 1 October 2026 | NA from 1 October 2026 | Yes |
| PS-1 | POS server | Client ID and Client Secret stored securely on POS Server | • Partner to confirm they are storing these details on their server | Yes | Yes | Yes | Yes |
| PS-2 | POS server | POS saves sales receipts for 540 days | • Partner to confirm they are storing sales receipts for at least 540 days. This is so that if a chargeback is filed, the merchant is able to provide proof of what was purchased at the time. | Yes | Yes | Yes | Yes |
| TA-1 | Tap to Pay API | App can fetch a Tap to Pay Transaction by transaction ID | • Confirm visually via App UI • Tyro to check that calls are returning 200 | Optional | Optional | Optional | No — verified by Tyro in production |
| TA-2 | Tap to Pay API | App can list Tap to Pay Transactions by reference | • Confirm visually via App UI • Tyro to check that calls are returning 200 | Optional | Optional | Optional | No — verified by Tyro in production |
| TA-3 | Tap to Pay API | App can list Tap to Pay Transactions by locationId | • Confirm visually via App UI • Tyro to check that calls are returning 200 | Optional | Optional | Optional | No — verified by Tyro in production |
| TS-1 | Transactions | Initialise App | • Embedded Payments launches successfully No Errors such as: • Attestation error • Invalid connection secret error • Tyro to test | NA | NA | Yes | No — verified by Tyro in production |
| TS-2 | Transactions | App is setting POS Info correctly | • Partner to send screen shots of code that shows the values being set for PosInfo and used accordingly • posName matches expected Partner's POS Name • posVendor matches what is expected of POS Vendor • posVersion matches a versioning format e.g. x.xx.xx or x.x • siteReference has some location reference • Tyro to check this matches what is expected for this POS | Yes | Yes | Yes | Yes |
| TS-3 | Transactions | Process payment — success | • Payment can be processed • Can tap card to pay • Success (App to display) • Tyro to check logs • Tyro to test | Yes | Yes | Yes | Yes. WebPOS can test this in production only, because webhook events are not supported in sandbox. |
| TS-5 | Transactions | Process payment — failed | • Processing payment with $666.xx • Failed status (App to display) • Tyro to check logs • Tyro to test | Yes | Yes | Yes | Yes. WebPOS can test this in production only, because webhook events are not supported in sandbox. |
| TS-6 | Transactions | App has option to provide customer with a receipt | • Check after a transaction processes that there is an option to provide the customer with a receipt — either digital or physical | Yes | Yes | Yes | Yes |
| TS-7 | Transactions | App can provide digital or physical receipt | • Check after a transaction processes that there is an option to provide the customer with a receipt either digital or physical • Ensure receipt is using Tyro's customerReceipt content returned in the transaction result • Tyro to test If Digital Receipt: • After transaction: • Digital receipt option shown that takes an email • Sending Digital receipt results in the given email receiving the Digital receipt If Physical Receipt: • After transaction: • Physical receipt option shown that can print a receipt • Printing Physical receipt results in the receipt being printed • Partner could send video evidence of the above | Yes | Yes | Yes | No |
| TS-8 | Transactions | Refund payment — success | • Refund option exists • Processing refund results in • Success status (App to display) • Tyro can check logs • Tyro to test | NA — refund capability not supported in current app release | NA — refund capability not supported in current app release | Yes | Yes |
| TS-10 | Transactions | Refund payment — failed | • Refund option exists • Processing refund results in • Failure status (App to display) • Tyro can check logs • Tyro to test | NA — refund capability not supported in current app release | NA — refund capability not supported in current app release | Yes | Yes |
| TO-1 | Android SDK onboarding | Provided App id and Public certificate to Tyro | • Partner to tick this off before going Live | NA | NA | Yes — SDK only | — |
| SF-1 | iOS SDK | Initialise App | • Embedded Payments launches successfully No Errors such as: • Attestation error • Invalid connection secret error • Tyro to test | NA | NA | Yes | — |
| SF-2 | iOS SDK | App is setting POS Information correctly | • Partner to send screen shots of code that shows the values being set for PosInfo and used accordingly • posName matches expected Partner's POS Name • posVendor matches what is expected of POS Vendor • posVersion matches a versioning format e.g. x.xx.xx or x.x • siteReference has some location reference • Tyro to check this matches what is expected for this POS | NA | NA | Yes | — |
| SF-3 | iOS SDK | Incompatible Embedded Payments device throws error | • Use an iPhone that does not support Embedded Payments (< iOS 18.6, < iPhone XS) • Should see error when trying to start Embedded Payments • Handled by App UI • Tyro to test | NA | NA | Yes | — |
| SF-4 | iOS SDK | Process payment (sandbox) — success | • Process Embedded Payments transaction with some amount > 0 • App informs user transaction was successful • Tyro to check logs • Tyro to test | NA | NA | Yes | — |
| SF-5 | iOS SDK | Process payment (production) — success | • Process Embedded Payments transaction with some amount > 0 • App informs user transaction was successful • Tyro to check logs • Tyro to test | NA | NA | Yes | — |
| SF-6 | iOS SDK | Process payment — failed (sandbox) | • Process Embedded Payments transaction with some amount > 0 • App informs user transaction failed • Tyro to check logs • Tyro to test | NA | NA | Yes | — |
| SF-7 | iOS SDK | App has option to provide customer with a receipt | • Check after a transaction processes that there is an option to provide the customer with a receipt either digital or physical | NA | NA | Yes | — |
| SF-8 | iOS SDK | App can provide digital or physical receipt | • Check after a transaction processes that there is an option to provide the customer with a receipt either digital or physical • Ensure receipt is using Tyro's customerReceipt content returned in the transaction result • Tyro to test If Digital Receipt: • After transaction: • Digital receipt option shown that takes an email • Sending Digital receipt results in the given email receiving the Digital receipt If Physical Receipt: • After transaction: • Physical receipt option shown that can print a receipt • Printing Physical receipt results in the receipt being printed • Partner could send video evidence of the above | NA | NA | Yes | — |
| SF-9 | iOS SDK | Refund payment (sandbox) — success | • Refund option exists • Processing refund results in • Success status (App to display) • Tyro can check logs • Tyro to test | NA | NA | Yes | — |
| SF-10 | iOS SDK | Refund payment (production) — success | • Refund option exists • Processing refund results in • Success status (App to display) • Tyro can check logs • Tyro to test | NA | NA | Yes | — |
| SF-11 | iOS SDK | Refund payment — failed (sandbox) | • Refund option exists • Processing refund results in • Failure status (App to display) • Tyro can check logs • Tyro to test | NA | NA | Yes | — |
| OI-1 | Other iOS SDK | In-app merchant education provided | • App has education materials present • Education Material may be in the form: • In-app merchant education video • In-app payment acceptance tutorials • Online training guides • In-person, online, or in-app training • Help center guidelines • Partner could send video or screen shot evidence of the above | NA | NA | Yes | — |
| OI-2 | Other iOS SDK | Apple terms and conditions accepted using Apple ID | • Tyro to tick if App appears to launch Embedded Payments | NA | NA | Yes | — |
| OI-3 | Other iOS SDK | Reader reconnects upon app resume | • From a suspended state: • App reconnects/resumes Embedded Payments • Tyro can see logs connection created/verified? • Tyro to test | NA | NA | Yes | — |
| OI-4 | Other iOS SDK | Reader updates are handled | • Reader Updates happen: • In the background • Progress/Completion status verifiable • Other? Describe • Partner could send video or screen shot evidence of the above | NA | NA | Yes | — |
| OI-5 | Other iOS SDK | Apple Entitlement | • Partner to confirm they have entitlements from Apple | NA | NA | Yes | — |
| EH-1 | Error handling | Partner is aware of the errors below and acknowledges they are handling them | • Partner to tick this off before going Live • Tyro to tick this off after testing in Sandbox and no unexpected errors • Tyro to tick this off after testing in Production and no unexpected errors | Yes | Yes | Yes | — |
ABOUT THE SDK-ONLY ROWS
TO-1, SF-1 to SF-11, OI-1 to OI-5 and EH-1 are stated in the source as "Required: Yes" without a per-path or sandbox-verification breakdown. Their path columns reflect that they are SDK-path tests (iOS SDK, or Android SDK onboarding); the sandbox column is left blank rather than inferred.
Test IDs are reproduced exactly as issued, so TS-4 and TS-9 are intentionally absent.
EH-1 above requires you to acknowledge that you handle the following errors.
InvalidTransactionParamException
- amountInCents must be positive and non zero
- amountInCents length cannot exceed 8 digits
- reference must not be blank
InvalidTransactionParamException
- amountInCents must be positive and non zero
- amountInCents length cannot exceed 8 digits
- reference must not be blank
INVALID_CONNECTION
- Connection Secret is invalid
SDK_VERSION_MISSING
SDK_UPGRADE_REQUIRED
- Current App version is < supported version
You should be aware of the below errors, but your integration should not trigger these.
Create Embedded Payments Connection
- 400 - When the provided payload is not valid.
- 403 - When you don't have the right permissions to create a Connection for the provided Reader ID
- 404 - When the provided readerId does not exist in our system
Create a Reader
- 400 - When the provided payload is not valid
- 403 - When you don't have the right permissions to create a Reader for the provided location or Merchant ID
List Readers
- 403 - When you don't have the right permissions to retrieve the Readers for the provided location or Merchant ID
Get a Reader
- 403 - When you don't have the right permissions to retrieve a Reader for the provided location or Merchant ID
Fetch a Embedded Payments Transaction
- 403 - When you don't have the right permissions to access the transactions
List Embedded Payments Transactions
- 403 - When you don't have the right permissions to access the transactions
- 404 - When the provided merchant or location ID does not exist in our system
List Embedded Payments Locations
- 403 - When you don't have the right permissions to fetch the locations
- 404 - When the provided merchantId does not exist in our system
List Embedded Payments Merchants
- 403 - When you don't have the right permissions to fetch the merchants
Fetch a Embedded Payments Merchant
- 400 - When the provided merchantId is not valid
- 403 - When you don't have the right permissions to fetch the merchant
- 404 - When the provided merchantId does not exist in our system
PDF MAY BE OUT OF DATE
This PDF predates the test matrix above (it was produced for the SDK-only certification process). Where the two disagree, the table above is current.