How a payment form works
The form collects the details, checks them as they are typed and submits them to a payment provider. Typical checks are the length and check digit of the card number, the card brand from its first digits, and an expiry date in the future.
On submission the details are exchanged for a token, any 3-D Secure step runs, and the payment is authorised. The merchant's order system receives the token and the result, not the card number.
Three ways to build a payment form
- Hosted page: the provider serves the whole form on its own domain
- Hosted fields: the provider serves each sensitive field in an iframe inside the merchant's page
- Direct form: the merchant's own fields, posting card data to the provider's API
The first two keep card numbers away from the merchant's servers and so narrow its PCI DSS scope. The third gives full control over the design and brings the merchant's site and servers into scope.
What a good payment form does
Small details move conversion: numeric keypads on phones, autofill and card scanning, clear inline errors, wallet buttons above the card fields, and the local payment methods of the buyer's country. Accessibility matters as much: labels, keyboard navigation and contrast decide whether some buyers can pay at all.
Payment form, checkout page or hosted checkout?
- Checkout page
- The whole page: basket, address, delivery and the payment form within it.
- Hosted checkout
- A payment form on a page that the provider hosts, reached by redirect.
Where a payment form shows up in a platform
Modules that do the work
- CheckoutA hosted checkout for cards, wallets, bank payments and crypto, routed to the best provider.
- Card acquiringCard acceptance on the phone, in store and online, through the acquirer you choose.
- Fraud & riskReal-time fraud scoring, limits and case management, with the risk engines you already trust.