Payment integration

The payment that goes through is rarely the problem. It’s the one that doesn’t: the phone is in a pocket, the app doesn’t open in time, the buyer changes their mind, or the reply from the payment provider never arrives. Your flow should handle that as calmly as a successful payment, and whether it does comes down to what happens to the order in the meantime.

What happens to the order while the payment is in progress?

The payment needs a state of its own, with its own lifetime. The order should be able to wait for payment without holding anything else up, until the payment is confirmed on the server or has expired. A few things need deciding before anything is built:

• What happens when the buyer cancels, or the payment is never confirmed.
• How a payment that arrives twice is handled, so the customer isn’t charged twice.
• How a refund is tied to the right order.
• Which cases still need a person, and where they show up.

Swish, Klarna and other payment methods

Each payment method has its own flow. Swish, the Swedish mobile payment app, is confirmed on the buyer’s phone, and with Klarna the amount is often only captured when the goods ship. Which methods suit you depends on what you sell and who you sell to. We look at the terms of your agreement with the payment provider before we promise anything.

Reconciling with the books

A payment isn’t finished when the money arrives. It also has to match the right order and the right entry in the books. How many payments a month does someone match by hand today, and how many never get matched at all? That’s what automatic reconciliation should be weighed against.

If the buyer needs to be identified, not just pay, BankID integration is separate work in the same flow. If the payment needs to be booked in your ERP, that’s ERP integration.