It is rarely either/or
The discussion gets framed as a choice between two providers. In practice it is a choice about architecture, and the two providers solve different halves of it.
Vipps MobilePay is distribution. It is already on the customer's phone, the customer knows what it looks like, and a purchase is three taps and a face. That is why it belongs at the checkout for Norwegian consumers, whatever sits behind it.
Stripe is a toolkit. Subscriptions, trials, proration, invoices, receipts, refunds, exports for the accountant, and API documentation good enough that developers do not have to guess. That is why it belongs where the business logic lives.
Klarna belongs in the same conversation
Klarna is available as a payment method through Stripe, so technically it is rarely a project of its own. The question is whether “pay later” suits what you sell. It often does for goods and less often for services delivered immediately – a sauna session from yesterday is a difficult thing to raise a dispute about. Decide from what you sell, not from the fact that the button exists.
The system that owns the truth
This is the decision that actually costs money to get wrong.
A payment provider can hold the truth about a subscription, or it can simply move money. Choose the first and the provider becomes hard to leave, and you can only answer questions the provider thought of. Choose the second and you write a little more code, but you own your own concepts.
We usually build it like this: an order or an agreement is a row on your side. Each payment provider is an adapter that reports events in – paid, failed, refunded, cancelled – and the system reacts to the event. Then a new payment method is one more adapter, and changing provider is not a rewrite of the product.
It is the same pattern as everywhere else in this codebase: events appended to a log that cannot be edited, and subscribers doing the work. It is boring, and that is precisely why it holds.
The three mistakes we see most
Letting the checkout define the product. When “what a membership is” only exists in a provider's dashboard, nobody can answer a customer question without logging in there. You notice the first time you change a price for existing members.
Treating webhooks as guaranteed. They arrive, but not always once, and not always in order. Your handling has to survive the same message twice and an old message late. This is almost always the cause when “the payment went through but the order is missing”.
Postponing reconciliation. What happened at the provider and what your system says should agree every day. Build that comparison last and you find the discrepancies when they are three months old.
How to decide in an afternoon
Three questions usually settle it:
- Who are the customers? Norwegian consumers: Vipps at the checkout, no debate. Businesses or abroad: start with Stripe and add Vipps if it is needed.
- One-off purchase or running agreement? Running agreements are where the models actually differ – decide who owns the agreement before you pick.
- How many places does a payment have consequences? One place is simple. Accounting, access, memberships and messaging are four, and then the event model above earns its keep.
HeatBooking does exactly this: payment, memberships, punch cards and door access hang off the same events, and the payment provider is one source among several rather than the authority.
If you want to make the choice properly, describe the service in the Living Brief and you get a sketch of the flow, the phases and a range in weeks straight back.