Use a real enrolled card and sandbox amount codes to trigger Click to Pay, Apple Pay, and Google Pay outcomes. Click an amount to copy it.

Click to Pay

You can test Click to Pay on the payment form through a sandbox PSP without charging real funds. The Click to Pay integration itself and its credentials are live.

Before starting tests, contact us to discuss configuration needs. Keep in mind that Click to Pay requires real cards and an active Click to Pay account, the same as Apple Pay and Google Pay. Sandbox test cards from this documentation do not work. Successful payments through the sandbox PSP do not debit funds.

Use accessible real email addresses and phone numbers for Click to Pay authentication. The live Click to Pay service requires a valid one-time password (OTP) sent to one of these contacts.

Do not pass the customer_email parameter when initializing the payment. If you pass it, Click to Pay automatically sends an authorization code to that email and attempts to access linked cards there.

To display Click to Pay on the payment form, pass clickToPayButtonParams during form initialization:

JavaScript 
clickToPayButtonParams: {
  enabled: true,
  saveRecognitionToken: true, // stores the token for 180 days
  supportedCardNetworks: ["visa", "mastercard"],
  height: 56, // value between 52 and 60
},

The Click to Pay button is always rendered above the card form. The card form must remain visible alongside Click to Pay, as required by card schemes. For layout rules, events, and full parameter details.

To simulate payment outcomes, use a real card enrolled in Click to Pay and set amount in cents to the same values as for Apple Pay or Google Pay:

  • 100 for success without 3DS
  • 666 for success with 3DS challenge
  • 555 for success with frictionless 3DS

Apple Pay or Google Pay

Sandbox provides a secure environment for simulating the integration of Google Pay and Apple Pay, without any risk to real bank accounts or transactions.

Before starting tests, contact us to discuss configuration needs. Keep in mind that Google Pay and Apple Pay digital wallets require real cards, and test cards do not work.

For the initial one-time payment, using an amount that is not listed below results in a standard approval. This ensures that all subsequent recurring payments using the same token are automatically approved. However, to trigger specific recurring or recurring auth payment outcomes, the initial transaction must use predefined amount values, which should be specified in cents. For example, an amount of 100 represents 1.00. Use the following values:

Using an amount different from the values listed above for the initial transaction ensures that subsequent recurring payments are always approved. This demonstrates the flexibility of the system in handling different transaction types.

Success AMOUNT 100 SUCCESS success without 3DS AMOUNT 666 SUCCESS success with 3DS AMOUNT 555 SUCCESS success with frictionless 3DS Error AMOUNT 1 ERROR 0.01 error : {code: 0.01 , message: "General decline"} AMOUNT 301 ERROR 3.01 error : {code: 3.01 , message: "Card is blocked"} AMOUNT 302 ERROR 3.02 error : {code: 3.02 , message: "Insufficient funds"} AMOUNT 3020 ERROR 3.02 error : {code: 3.02 , message: "Insufficient funds"} with frictionless 3DS AMOUNT 304 ERROR 3.04 error : {code: 3.04 , message: "Transaction is declined by issuer"} AMOUNT 308 ERROR 3.08 error : {code: 3.08 , message: "Do not honor"} AMOUNT 3080 ERROR 3.08 error : {code: 3.08 , message: "Do not honor"} with 3DS AMOUNT 310 ERROR 3.10 error : {code: 3.10 , message: "Suspected fraud"} AMOUNT 403 ERROR 4.03 error : {code: 4.03 , message: "Restricted card"} Processing AMOUNT 549 PROCESSING processing AMOUNT 649 PROCESSING processing with 3DS AMOUNT 749 PROCESSING processing with frictionless 3DS