Enter the card once. Pay in one click from then on.
The first payment saves the card as a token. Everything after it runs on that token — a returning customer confirming in one tap, or a renewal you charge while they are away.
•••• 4242
•••• 8817One-click, from the customer's side.
Two steps, and the card is typed in only the first of them. Everything the customer sees here is rendered by Waffo's checkout — the saved-card list, the one-tap confirm, and the extra check when risk asks for one.
The customer chooses to save the card while paying. It is stored only once that payment goes through — an attempt that failed leaves nothing behind.
Saved only once the payment succeeds.
One tap. 3DS can still be challenged when risk asks for it.
You store a token, not a card.
One-click is a stored card doing the work — and which credential goes to the network is Waffo's decision, not a branch you write.
One token, one customer, one card
The token is scoped to that customer and that card under your Waffo account. It is not a card number and not a wallet, and it is worth nothing anywhere else. The card details stay with Waffo.
Unbinding is final
An expired token can be brought back rather than re-collected, and it can still be unbound. Unbinding is the end of it: a card the shopper adds again comes back as a new token.
Risk checks do not step aside
Which credential actually goes to the network is Waffo's decision, not a branch you write. And 3DS is still applied dynamically based on risk, so a one-click charge can still be challenged.
What you actually write.
Five surfaces, in the order you would write them. A binding is started on your server, the card is submitted from the browser, and everything after that is your normal order call with a token where the card number used to go.
Your server opens a tokenization session and gets back a session id. The API key never leaves your backend.
Read the tokenization guidePOST /api/v1/tokenization/generate { "tokenRequestId": "tkr_20260827_001", "merchantUserId": "USER_001", "tokenType": "CARD", "notifyUrl": "https://yourstore.com/webhooks/waffo" } # 200 -> { "tokenSessionId": "tks_9f2c..." } # Hand the session id to the browser. Your API key stays here.
The token plugs into the rest of the stack.
A saved credential is not a thing on its own — it lives on the checkout UI, is reused by every renewal, and still goes through the same risk checks on each charge.
Checkout
Prebuilt hosted and embedded payment UIs, or your own form — the credential one-click saves is the one those UIs reuse.
See checkoutSubscriptions
The same stored card is the one each renewal charges: plans, renewals, trials and receipts all sit on it.
See subscriptionsFraud prevention
A reusable credential does not skip risk — every charge is still assessed, and Waffo applies 3DS dynamically based on risk.
See fraud protectionFrequently asked questions about one-click payments.
No. What you store is a token scoped to that customer and card under your account. The card details stay with Waffo, and the token is worth nothing outside your account.
Their saved cards, and one confirm. A CVV field appears only on the one charge where a card-network token is not on file yet; after that charge it does not come back for that card. 3DS can still be challenged when risk asks for it.
You unbind it with the token you hold — which works even if that token has expired. The token is then canceled for good; a card the customer adds again comes back as a new token.
You are. Your terms have to say what you will charge, how often, how the amount is worked out, and how the customer cancels, and the customer has to agree to it. Waffo charges against the mandate that first payment created; it cannot write the terms for you.
Companies go live on Waffo. Developers start on Pancake.
Two paths, one promise: you build the product, Waffo runs the payments.