Go-live checklist

Check off these steps before launching your integration in production.

The steps below will help to ensure you have a complete implementation.

Test in the sandbox

Before going live, test your integration in the sandbox. For each payment method that you offer:

• Make a successful payment.

• Make an unsuccessful payment.

• Make a successful payment after an unsuccessful one to test you update a client session secret.

• Make a successful payment with 3DS.

• Make an unsuccessful payment with 3DS.

Use the test card numbers below to make payments:

Card Name	Card number	Expiry Date	CVV	3D security	Status
Test Cardholder	5200 0000 0000 1005	12/29	020	No	Successful
Test Cardholder	5200 0000 0000 1096	12/29	020	2.0	Successful
Test Cardholder	4456 5300 0000 1013	12/29	341	No	Decline

Handle 4xx and 5xx responses

For each integration, you need to make a call to our API. In cases API calls fail, you'll receive an error message with an HTTP status code and a traceId containing the unique identifier of the failing request. You should build some logic on your server to handle any errors. For example, you can handle them as exceptions.

Update the client session secret

You need to update the client session secret every time you make any changes to the payment intent or the payment is declined. These tokens are one-time use only. If you need to retry a payment, you must generate a new token.

Check the domain verification file

If you use the wallet component to enable Apple Pay, you must host the domain verification file on each domain you want to use, including subdomains, under the following path: https://yourdomain/.well-known/apple-developer-merchantid-domain-association.

Make sure that the file is downloadable and served at the correct location, as Apple will use this location to verify the validity of your domain. If your domain is protected from public access and you wish to complete domain verification, you should allow Apple IP Addresses for Domain Verification.

Configure and test your webhooks

To test webhooks before you create or configure a live service, you can use one of several request logging sites, for example, WebHook Tester. Alternatively, use a service like ngrok.

• Our webhooks provide "at least once" delivery of events. This means that you might get the same event several times. Your application needs to be built to handle those cases. You can detect duplicate events by comparing the id to previous events.

• Make sure you're receiving all notifications you need for the integration.

• Check URL you provide for notifications. It must be publicly accessible and be HTTPS as well.

• Ensure you have set up webhooks in the live mode exactly as you did in the test.

You can manage webhooks in the Developer Portal or by using our API.

Switch API keys

• Check that your integration doesn't cause your API keys to be publicly available.

• Switch your secret key to production one with the prefix sk_prod_. If you haven't a production key, use the Developer Portal to create it.

Check the result

Make your first live API call to make sure that your production key is working. Open your checkout page to see the result.