Testing a Browser Payment Integration
Once you have set up your account with the payment website provider and built your integration, you should test your integration using your test merchant profile (your merchant ID starting with 'TEST'). The Tyro eCommerce Payment Gateway provides a simulator to simulate the payment provider's website.
Testing the Initiate Browser Payment call
You can use the order.reference field when making an Initiate Browser Payment request to trigger different values for response.gatewayCode.
transaction.reference field.Sending '.FAIL<code>' in order.reference returns:
- The
response.gatewayCode=<code> if <code> is a valid value forresponse.gatewayCode. - The
response.gatewayCode=UNKNOWNif <code> is not a valid value forresponse.gatewayCode.
For other browser payments (Alipay, Boleto Bancário, GrabPay, iDEAL, , Multibanco, OXXO, POLi, , SEPA, WeChat Pay, Afterpay)
You can use the following values (WITHOUT the '.FAIL' prefix) in the order.reference field when making an Initiate Browser Payment request to trigger different values for response.gatewayCode.
| order.reference | response.gatewayCode | Behavior |
|---|---|---|
| TEST-SUCCEED | APPROVED | The transaction will succeed immediately. |
| TEST-FAIL-NOTFOUND | DECLINED | The transaction will be declined immediately. |
| TEST-FAIL-DECLINE | DECLINED | The transaction will be declined immediately. |
| TEST-PENDING | SUBMITTED | The transaction will remain pending indefinitely. |
| TEST-FAIL-THEN-SUCCESS | SUBMITTED then DECLINED then APPROVED |
After 30s the simulator will send a notification and fail the transaction. 60s later the simulator will send another notification and the transaction will succeed. |
| TEST-FAIL-INIT | SUBMITTED then DECLINED |
After 30s the simulator will send a notification and fail the transaction. |
| TEST-SUCCESS-INIT | SUBMITTED then APPROVED |
After 30s the simulator will send a notification and the transaction will succeed. |
| TEST-TIMEOUT-THEN-SUCCESS | SUBMITTED then ACQUIRER_SYSTEM_ERROR then APPROVED |
After 30s the simulator will send a notification and mark the transaction as timeout. 60s later the simulator will send a notification and the transaction will succeed. |
| TEST-QUICK-TIMEOUT-THEN-SUCCESS | SUBMITTED then ACQUIRER_SYSTEM_ERROR then APPROVED |
After 5s the simulator will send a notification and mark the transaction as timeout. 5s later the simulator will send a notification and the transaction will succeed. |
| TEST-FAIL-TIMEOUT | SUBMITTED then ACQUIRER_SYSTEM_ERROR |
After 30s the simulator will send a notification and mark the transaction as timeout. |
| TEST-TIMEOUT | TIMED_OUT | The simulator mimics a timeout scenario. The transaction fails after a delay of 31 seconds. |
| TEST-NO-RESPONSE | UNSPECIFIED_FAILURE | The simulator mimics a scenario where the transaction could not be processed. |
Simulating the results from a payment website provider
The browser payment simulator:
- Has a basic branding of the payment website provider.
- Is only available in English.
For PayPal Payments
- The payment details provided in the Initiate Browser Payment request are displayed.
- You must select a PayPal payment result:
SUCCESSPENDINGCANCELUNKNOWNERRORTIMED_OUT
- For pending results you can simulate getting a notification by setting the delay before receiving the notification and the desired result of the notification.
- After you click "Pay Now" or "Continue" the browser is redirected back to the URL provided in the Initiate Browser Payment request.
- Use the following values in the
order.referenceortransaction.referencefield when making an Initiate Browser Payment request to trigger different values forresponse.gatewayCode.Order.Reference or transaction.reference response.gatewayCode Order Status Behavior PP.400.BADREQUEST DECLINED FAILED The transaction will be declined immediately. PP.PENDING.AUTHORIZATION APPROVED CAPTURED The transaction will succeed immediately. PP.PENDING.NONE PENDING CAPTURED The transaction will remain pending indefinitely. PPP.400.CAPTURE_AMOUNT_LIMIT_EXCEEDED DECLINED FAILED The transaction will be declined immediately. PP.400.TIMEOUT DECLINED FAILED The simulator mimics a timeout scenario. The transaction fails immediately. PP.400.INVALID_REQUEST DECLINED FAILED The transaction will be declined immediately. PP.400.INSUFFICIENT_FUNDS INSUFFICIENT_FUNDS FAILED The simulator mimics an insufficient fund scenario. The transaction fails immediately. PP.400.ORDER_VOIDED DECLINED FAILED The transaction will be declined immediately.
If you are integrating with PayPal for the first time, then you must send the following values as a part of order.reference field while testing your integration
Use the following values in the order.reference field when you make an Initiate Browser Payment request to trigger different values for response.gatewayCode.
| Order.Reference | response.gatewayCode | Order Status | Behavior |
|---|---|---|---|
| A_M | DECLINED | FAILED | The transaction gets declined immediately. |
| P_C | PENDING | CAPTURED | The transaction will remain pending indefinitely. |
| I_D | DECLINED | FAILED | This scenario is for mocking Funding Failure scenario. For more information, see the Handle funding failures topic. |
For Other Browser Payments (Alipay, Boleto Bancário, GrabPay, iDEAL, Multibanco, OXXO, POLi, SEPA, WeChat Pay, Afterpay)
- The payment details provided in the Initiate Browser Payment request are displayed.
- You must select a payment result:
SUCCESSDECLINEBAD_REDIRECT_CHECKSUM(not recommended for testing)
- For pending results you can simulate getting a notification by setting the delay before receiving the notification and the desired result of the notification.
- The browser payments service provider will return a redirect URL which will be passed on to you.
- You should then redirect the payer to the browser payment specific page using the URL provided.
- After completing the payment details, the browser payments service provider will process the transaction request and the Tyro eCommerce Payment Gateway will redirect the payer back to your site.
Testing transaction filtering rules for IP address range
If you have configured Transaction Filtering rules for IP Address Range, you can simulate a reject of a prohibited IP address by setting up the following:
- Configure a range of IP addresses to reject in the IP Address Range rules in Merchant Administration.
- Provide an IP address within that range in the
order.referencefield when submitting anInitiate Browser Paymentrequest.- For browser payments, Alipay, Boleto Bancário, GrabPay, iDEAL, , OXXO, POLi, SEPA, WeChat Pay, Afterpay the value should be submitted in the format '
TEST_IP_ADDRESS<nnn.nnn.nnn.nnn>'.This test is not applicable to Multibanco browser payment method. This is because the payer's browser is not redirected to the Multibanco website hence the gateway cannot retrieve the payer's IP address. - For other browser payments, the value should be submitted in the format '
.TEST_IP_ADDRESS<nnn.nnn.nnn.nnn>'.
<nnn.nnn.nnn.nnn> represents a valid IPv4 format which can contain between 7 to 15 characters. - For browser payments, Alipay, Boleto Bancário, GrabPay, iDEAL, , OXXO, POLi, SEPA, WeChat Pay, Afterpay the value should be submitted in the format '
If the IP address causes the transaction to be rejected, the risk.response.gatewayCode will be returned as 'REJECTED' in the Retrieve Transaction operation.
There are no specific tests provided for simulating a reject of black-listed countries in the IP Country Transaction Filtering rules; however, you may simulate this scenario by adding all countries to the reject list.