One-click payment
The customer enters their card once. Every order after that is a single button.
On the first payment the card is stored as a token tied to the customer's profile. The number stays in the certified environment. You only ever see the last four digits.
The effect is clearest with returning customers and on mobile, where every input field costs conversion.
What you get
One button
No card entry on a repeat order.
Tokenisation
Details are held outside your system.
Several cards
The customer picks which saved card to use.
3-D Secure when needed
A check only when the risk calls for it.
Works with subscriptions
The same token powers recurring billing.
Fewer abandoned baskets
Especially on mobile orders.
How it works
First order
The customer pays and agrees to save the card.
Token
We store a token tied to their profile.
Repeat order
You show the last four digits and a pay button.
Confirmation
The payment goes through at once, with no new fields.
Every field in checkout costs you sales
Abandoned baskets are no mystery. The customer decided to buy, reached payment and met a form with twelve fields, a forced registration and sixteen digits from a card that is in the other room. Some of those people never come back.
One-click payment removes exactly that step. A customer who has bought from you before sees their saved card as the last four digits and confirms. With a wallet such as Apple Pay or Google Pay they confirm with a finger or a face and never type an address, because the details come from the phone.
The effect is largest on mobile, where entering a card is most painful and where most traffic now arrives for the majority of shops.
How the card is kept without you keeping it
A saved card is not a number in your database. On the first payment the card details go to the certified environment and a token comes back. The token works only for your account and is worthless to anyone who steals it.
On the next order the customer sees Visa •••• 4242 and confirms. If the rules call for 3-D Secure it is shown, but on a repeat purchase from a known customer an exemption often applies and the step disappears.
The customer has to be able to delete a saved card as easily as they saved it. That is not courtesy but a requirement, and the API has a method for exactly that.
What not to do
Do not save the card silently. The checkbox has to be visible and unticked by default. Quiet saving is a reliable road to disputes and lost trust.
Do not show a saved card on a device that has not been recognised as the same customer. If someone gets into another person's account, the last four digits and a pay button are precisely what you do not want them to find.
Do not rely on wallets alone. Apple Pay covers iPhone, Google Pay covers Android, and there are still people at a desktop with a card in hand. The three work together, not one instead of another.
How many steps a payment can take
It helps to count steps from the customer's side rather than the code's. Here are three typical paths in the same shop.
A new customer with no wallet: picks the product, goes to the basket, enters email and delivery address, chooses a courier, types sixteen digits, expiry and CVC, confirms in the banking app, comes back. Around nine separate actions and two app switches.
A new customer with Apple Pay or Google Pay: picks the product, taps the wallet button, confirms with a finger. Address and email come from the wallet. Three actions.
A returning customer with a saved card: picks the product, confirms the saved card, done. Two actions.
The gap between nine actions and two is not closed by a discount. That is why checkout work usually returns more than one more traffic campaign.
Check your own checkout
Go through your site as a customer, on a phone, and note which of these is true.
- Can someone pay without registering
- Are Apple Pay and Google Pay visible before the card form
- Is the card saved with a visible, unticked checkbox
- Can the customer delete a saved card themselves
- Does a numeric keypad open on the card field
- Does the basket survive a failed payment
Questions about this
Does the customer need an account on my site?
For a saved card, yes, because the card is tied to a profile. For wallets, no: Apple Pay and Google Pay work for guest checkout too.
What if the customer changes card?
They add a new one at the next purchase and can delete the old one themselves. For a reissued card, the account updater service often supplies the new number automatically.
Does this help against fraud or hurt?
It helps, on balance. A repeat purchase from a known device with a known card is a low-risk signal, which the fraud rules use to let the transaction through without friction.
How long is the integration?
If you already take payments with us, adding a saved card is a few hours of work. Wallets also need domain verification, which takes a little longer.
Does it work for subscriptions?
Yes, it is the same tokenisation. The only difference is the consent, which for a subscription has to cover future automatic payments as well.
How much can conversion rise?
It depends where you start from. A shop with a long form and forced registration usually sees the biggest difference. The number varies per business, so it is more honest to measure it on your site than to promise a percentage.
What happens to saved cards if I change my site platform?
The tokens stay valid, because they live with us and not in your site. On migration you carry over the link between the customer profile and the token, and customers never re-enter their cards.
Do I need separate consent to save the card?
Yes. It is distinct from consent for the payment itself and is collected with a visible checkbox. We keep the record of when and how it was given, which earns its keep in a dispute.
Ready to start accepting payments?
Send us an enquiry and you will get a concrete quote with calculated fees for your business, usually within one business day.