Four stages, from basket to confirmed order
The basket confirmed, the card entered in a Stripe field, strong authentication when the bank asks for it, then the order confirmed when Stripe notifies the server.
Case study · client application, online retail
A payment form rebuilt with Stripe, for an online retailer.
The retailer's payment flow was seen as complicated and not very reassuring. We rewrote it around Stripe: card details are entered in fields provided by Stripe, and strong authentication opens within the flow when the bank asks for it. The retailer's server keeps no bank data.
01/BackgroundWhere we started
A payment step that worries customers makes them leave before the end
The starting point: a complicated, not very reassuring flow that customers abandoned before paying. For each sticking point, what the form does.
- 01Customers abandoned at the moment of payment, faced with a complicated and not very reassuring flow.A short form, card fields provided by Stripe, clear error messages as you type.
- 02The strong authentication required in Europe adds a step that many forms handle badly.The 3D Secure check opens within the flow when the bank asks for it, then the payment resumes.
- 03Storing card numbers makes the retailer liable.Card numbers go straight to Stripe; the server only handles payment identifiers.
- 04A thank-you page does not prove that the money has arrived.The order is confirmed when Stripe's notifications arrive, not when the browser returns.
02/What we builtDelivered to the client
A short payment flow, where the card never touches the server
Everything to do with the card stays with Stripe; the form, the checks and the confirmation are our code.
- 01Payment intent. Each payment is created on the server side with Stripe's Payment Intents API.
- 02Stripe Elements card fields. Card number, expiry date and security code are entered in fields served by Stripe.
- 03Validation as you type. Number, date and security code are checked live, with a clear message under the field.
- 04Strong authentication. The 3D Secure checks requested by the bank open within the flow.
- 05Confirmation by Stripe. The server listens for Stripe's notifications (webhooks) to confirm the order and update its status.
- 06Form protection. Tokens against request forgery, and inputs sanitised against script injection.
- 07Limit on attempts. The number of tries is capped, against bursts of attempts.
- 08Transaction log. Every transaction is logged, so that what happened can be traced.
03/One diagramTypeset diagram, not a screenshot
A diagram of the flow, in the absence of a screenshot
The original screenshots are lost and the code has not been restarted in test mode: this diagram follows the payment, step by step.
04/TechnologiesWhat we chose, and why
Payment handed to Stripe, the rest written by hand
Everything that touches the card stays with the payment provider; the flow around it is our code, checked from end to end.
- ServerPHP 8.2, MVC architecture.
- PaymentStripe's Payment Intents API; Stripe notifications (webhooks) to confirm each payment.
- InputStripe Elements for the card fields; JavaScript without a library for validation as you type.
- Authentication3D Secure, triggered when the bank asks for it.
- ProtectionEncrypted exchanges, tokens against request forgery, sanitised inputs, a limit on attempts.
- TracesA log of every transaction.
05/Further readingRelated services
For a site that takes payments without worrying anyone
What next
Card payment to add to your site, or to rebuild?
Card fields, strong authentication, a confirmation you can rely on: tell us about your shop or your service, and we will tell you what is feasible, with a timeline and a rough price.
Discuss your project
Reply within 24 working hours, from one of the two founders. Or by phone: +33 7 59 96 14 99.