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.
  1. The payment details provided in the Initiate Browser Payment request are displayed.
  2. You must select a PayPal payment result:
    • SUCCESS
    • PENDING
    • CANCEL
    • UNKNOWN
    • ERROR
    • TIMED_OUT
  3. For pending results you can simulate getting a notification by setting the delay before receiving the notification and the desired result of the notification.
  4. After you click "Pay Now" or "Continue" the browser is redirected back to the URL provided in the Initiate Browser Payment request.
  5. 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.

For UnionPay SecurePay Payments

  1. The payment details provided in the Initiate Browser Payment request are displayed.
  2. 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
  3. 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)

  1. The payment details provided in the Initiate Browser Payment request are displayed.
  2. You must select a payment result:
    • SUCCESS
    • DECLINE
    • BAD_REDIRECT_CHECKSUM (not recommended for testing)
  3. For pending results you can simulate getting a notification by setting the delay before receiving the notification and the desired result of the notification.
  4. The browser payments service provider will return a redirect URL which will be passed on to you.
  5. You should then redirect the payer to the browser payment specific page using the URL provided.
  6. 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>'.
      • <nnn.nnn.nnn.nnn> represents a valid IPv4 format which can contain between 7 to 15 characters.

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.

Copyright © 2023 MasterCard