Online payments from scratch

An online purchase looks simple to the customer, but behind the Pay button are several parties and steps your app has to handle. This guide walks through them in the order they happen, what differs between a digital product and one that ships, and what the same step is called at the eleven payment providers you can try in Veracity Pay.

Who does what

• The customer picks products, enters details and approves the payment, often with BankID, 3-D Secure or in the Swish app.
• The shop – your app – knows what is sold and at what price. It creates the payment at the payment service from its server, with a secret key, and creates the order once the payment is done.
• The payment service (PSP: Stripe, Nets, Klarna/Kustom, Swish and others) shows the checkout, talks to the banks, notifies the shop and pays out the money. It carries the responsibility for card data, so your app never needs to see a card number.
• The bank that issued the card, or the customer's bank for Swish and bank transfers, approves and reserves the amount.

Contracts and know your customer (KYC)

Before a real payment service lets you take payments, it has to know its customer. KYC stands for Know Your Customer and is required by anti-money-laundering law. It usually means the payment service:

• requires a company with a registration number – often not a private person;
• checks who owns and controls the company (beneficial owners) and has the signatory sign with BankID;
• wants to know what you sell, to whom and how much, and to see a website with terms, prices, return rules and contact details;
• assesses the risk and approves you, which can take from a few days to a few weeks.

Swish also needs an agreement with your bank and a certificate, and cards need an acquirer to approve you. That is why it is hard to build payments before the idea is finished. Veracity Pay needs none of it: you create an account with a name, an e-mail and a code, as a private person too, and go through the real provider's checks once you know which one you want.

The purchase flow step by step

1. The customer fills the cart and goes to the checkout.
2. The shop's server creates the payment at the payment service: amount, currency, order lines with VAT, and addresses to send the customer back to. The answer is an address of the checkout or a snippet to show on the page.
3. The customer pays in the checkout and verifies.
4. The bank approves and reserves the amount. No money has moved yet.
5. The customer is sent back to the shop and sees a thank-you page.
6. The payment service tells the shop's server, with a webhook or push, that the payment is done.
7. The shop creates the order and delivers.
8. The shop captures the amount – at once or when the goods ship.
9. The payment service pays out to the shop's account, minus its fees, often a few days later. In Veracity Pay no money moves and there are no fees.

Reserve and capture

Most card payments happen in two steps. First the amount is reserved (authorization), then it is captured. The card networks' and payment services' rules say you capture once the goods ship or the service is delivered.

• Digital product, service or subscription: delivered at once, so the shop captures at once. Many services do it for you (auto capture, charge: true).
• Physical product: reserve at the purchase and capture when the parcel ships. If only part ships, capture only that part and release the rest. A reservation lasts a limited time, often 7 to 28 days depending on the service and the method.
• Invoice and instalments: the payment service runs a credit check at the purchase. When you ship, you activate the invoice (that is the capture), and the customer then pays the payment service, not you.
• Swish: has no reservation; the money moves when the customer approves in the app.

Trust the webhook, not the redirect

The customer coming back to the thank-you page proves nothing: the tab can close, the phone can lose coverage, or someone can type the address. So the payment service also notifies your server directly, and retries until it answers 2xx.

• Check the signature before doing anything, so nobody else can pretend to be the payment service.
• Handle each event once: the same webhook can arrive twice.
• Read the payment from the service when the notice carries no signature (push at Kustom, Svea, Swish) – trust the answer, not the call.
• Answer quickly and do the heavy work afterwards.

Three kinds of checkout

• Hosted page (redirect): the customer goes to the service's page and back. The simplest to build and the least responsibility for you.
• Embedded checkout: the service's checkout shows in a frame on your page (Kustom, Svea, Walley, Qliro, Nets embedded). The customer never leaves the shop.
• Components: you build the page and drop in the service's card fields (Stripe Payment Element, Adyen Drop-in). The most control, the most to build.

After the purchase

• Refund: money back from what was captured, all or part.
• Release the reservation: what was not captured can be released (cancel, void) – no money has moved, so nothing needs paying back.
• Chargeback: the customer disputes the purchase with their bank, which takes the money back from the shop. At real services it costs a fee; in Veracity Pay there are no fees.

Recurring payments

For subscriptions and payments without the customer present, the payment service saves the method as a token at the first purchase, when the customer agrees and verifies. After that the shop charges the token without the customer (merchant initiated). The card can also be registered without a purchase, with an amount of zero.

Plan for declined charges: cards expire and accounts run dry. Retry a few days later and ask the customer for a new card if it keeps failing.

Company purchases

If you sell to companies, the checkout asks for the organisation number and an invoice reference, and the invoice goes to the company. Ledyer and Two sell only to companies, and Svea, Walley and Qliro offer it as an option. The test companies are in each provider's guide; for Svea, Walley and Qliro, 556677-8899 works.

The same steps, different names

Every provider has its own words and paths for the same thing. The table shows the main ones; the details, and what Veracity Pay does not emulate, are in the documentation per provider.

Try all of this in Veracity Pay

Veracity Pay emulates the eleven providers as closely as their public documentation allows, without real money and without fees. You can choose each payment's outcome, move the clock to test renewals and see every webhook in the dashboard.

• Shop in the demo shop and see the requests to each provider.
• Create a test account – name, e-mail and a code, no company needed.
• Read the documentation for each provider.
• Missing something? Request a payment method or suggest a payment partner.