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 Mastercard 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.

For a Void transaction, you must use transaction.reference field.

Sending '.FAIL<code>' in order.reference returns:

The response.gatewayCode=<code> if <code> is a valid value for response.gatewayCode.
The response.gatewayCode=UNKNOWN if <code> is not a valid value for response.gatewayCode.

For Other Browser Payments (Alipay, Boleto Bancário, Bancontact, Giropay, GrabPay, iDEAL, Klarna Financing, Klarna Pay Later, Klarna Pay Now, Multibanco, OXXO, POLi, SEPA, Sofortbanking, WeChat Pay)

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

After you are onboarded, the PayPal sandbox ID is set to a dummy value so that you can test your integration with your test profile. Once your third-party permission is granted, the dummy value will get replaced with the actual PayPal account ID.

The payment details provided in the Initiate Browser Payment request are displayed.
You must select a PayPal payment result:

SUCCESS
PENDING
CANCEL
UNKNOWN
ERROR
TIMED_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.reference

or transaction.reference field when making an Initiate Browser Payment request to trigger different values for response.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 UnionPay SecurePay Payments

The payment details provided in the Initiate Browser Payment request are displayed.

You must select a card number to trigger a UnionPay SecurePay payment result:

Test Card Number	Transaction Response Gateway Code
2223000000000007	APPROVED
4005550000000019	ACQUIRER_SYSTEM_ERROR
4508750015741019	UNKNOWN
6011000991300009	NOT_SUPPORTED
5149612222222229	DECLINED
4012000033330026	TIMED_OUT

After you click "Proceed" the browser is redirected back to the URL provided in the Initiate Browser Payment request.

For Other Browser Payments (Alipay, Boleto Bancário, Bancontact, Giropay, GrabPay, iDEAL, Klarna Financing, Klarna Pay Later, Klarna Pay Now, Multibanco, OXXO, POLi, SEPA, Sofortbanking, WeChat Pay)

The payment details provided in the Initiate Browser Payment request are displayed.
You must select a payment result:
- SUCCESS
- DECLINE
- BAD_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 Mastercard 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.reference field when submitting an Initiate Browser Payment request.
- For browser payments, Alipay, Boleto Bancário, Bancontact, Giropay, GrabPay, iDEAL, Klarna Financing, Klarna Pay Later, Klarna Pay Now,, OXXO, POLi, SEPA, Sofortbanking, WeChat Pay, 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>'.

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.