How the Flow Works
Three things to note:- Your API key stays on your server. The browser only gets a session token, which is valid for 5 minutes.
- The 3D Secure result is stored on the token. You do not pass it to the charge yourself. When the gateway supports 3D Secure data, PCI Booking adds it to the charge automatically. See 3D Secure and the UPG.
- The charge is an API call from your server. There is no payment page for the gateway, and the cardholder never leaves your page.
Before You Start
You need:- A PCI Booking sandbox account and its API key.
- Your PCI Booking username. The card entry form uses it as the
brandparameter. - For your first test, nothing else. The examples charge through
NULLSuccess, PCI Booking’s built-in test gateway, so you do not need a PSP account yet.
The Checkout Page
Save this aspublic/checkout.html. It loads the card entry form, uses your own Pay button to submit it, and sends the card token to your server.
checkout.html
public/card-failed.html, a short page that says the card was not accepted. When the card is rejected, the card entry form loads this page inside the iframe, and your page also receives a CardSubmitFailure message. The example then loads a fresh form so the guest can try another card.
How the page works:
submitWithPostMessage=trueremoves the form’s own submit button. Your page submits the form by sending it thesubmitmessage.postMessageHostmust be the exact origin of your page. Without it, the form sends no messages at all.- Check
event.originbefore you act on a message, as the listener above does, and send the form only the documentedsubmitandvalidatemessages. - The
CardSubmitSuccessmessage carries the card token, the masked card number, the card type and the expiry date. It does not carry the 3D Secure result. The result is stored on the token.
The Server
The server does two things: it starts a temporary session for the card entry form, and it charges the token. Your API key is read from an environment variable.checkout.html and card-failed.html in a public folder, install Express with npm install express, set PCI_BOOKING_API_KEY to your sandbox API key, and run node server.js. Because postMessageHost must match your page’s origin, open the page through the server, not as a local file.
Moving From the Test Gateway to Your PSP
When the flow works withNULLSuccess, switch to your own PSP:
- Store your PSP credentials in PCI Booking, see Gateway Credentials.
- In the charge request, remove the
PaymentGatewayobject and add?credentialsId=YOUR_CREDENTIALS_IDto the URL. - Read the gateway-specific guidance for your PSP. Some PSPs need extra fields, such as more
PayerDetails.
Making Sure the Card Has 3D Secure
This example setsUnavailThreeDSAuth=Reject. If the card cannot complete 3D Secure, for example because the card is not enrolled, it is not tokenized: the cardholder sees your failure page and your page gets CardSubmitFailure. With the default, Accept, the card is stored without 3D Secure data, and a PSP that requires 3D Secure will then decline the charge.
A card that fails the 3D Secure challenge is always rejected, whatever the value of UnavailThreeDSAuth.
Troubleshooting
Related
- Live Demos. The same flow running on a demo checkout page.
- Hosted Card Entry Form. All the ways to use the form.
- PSD2 and 3D Secure. How PCI Booking handles 3D Secure.
- Universal Payment Gateway. Charging, authorizations, refunds and fallback gateways.
- Testing and Going Live. Test cards and the go-live checklist.

