A payment layer that doesn't lock you to one processor
Plenty of commerce platforms bake in a single payment processor and bill you to leave it. Vendure takes payment through a PaymentMethodHandler: a small interface that wraps whatever provider you use. The storefront calls one mutation, addPaymentToOrder, and the handler talks to Stripe, Mollie, a bank-transfer back office, or an in-house gateway.
Switching providers stays at the handler boundary, so your checkout code never changes. Ready-made handlers for common providers already live in the community payment plugins, so most teams start from a working integration instead of a blank file.
One payment model, any provider behind it
Vendure models payments once. Providers plug in behind a single handler interface, so checkout and refunds behave the same no matter who processes the money.
The payment foundation is part of Vendure Core. Store credit and gift cards extend it as a native tender on Vendure Platform.
Provider-agnostic handlers
PaymentMethodHandler is the one interface every integration implements: create, settle, cancel, and refund. The storefront only ever calls addPaymentToOrder, so swapping one provider for another never reaches your checkout code.
Single-step or two-step capture
Authorize and capture in one move at checkout, or authorize now and settle later on fulfilment. The same handler shape covers card gateways, bank transfer, and payment on delivery.
Refunds and cancellations
Full and partial refunds run through the handler and a dedicated refund state machine. Cancel an authorized-but-uncaptured payment to release the hold on the provider's side.
A payment state machine you can extend
Every payment moves through Created, Authorized, Settled, Declined, Cancelled, and Error. Add your own states and transition guards with a PaymentProcess when a provider needs them.
More than one tender per order
Eligibility checkers decide which methods a customer sees at checkout. A single order can carry more than one payment, so you can split a total across methods or top up a partial payment.
Authorize at checkout, capture when you ship
Most online payments split into two parts: authorization, where the customer's bank confirms the transaction, and settlement (or capture), where the funds move from the customer to the merchant. Vendure lets the handler decide whether those happen together or apart, so the same model fits a card gateway and a payment-on-delivery flow.
The whole payment layer is open source
The payment foundation lives in @vendure/core, out in the open. The handler interface, the state machine, the eligibility checkers, and the refund flow are all in the public repo, and the code running production checkouts is the code you can read.
Local development uses the built-in DummyPaymentHandler, so you can build and test the full checkout before wiring a real provider. When you need custom behaviour, a PaymentProcess adds states and guards on top of the defaults without forking anything.
Trusted by complex B2B commerce and enterprise retail.
What teams ask about Vendure payments
Questions we hear from engineering and commerce teams wiring up a real checkout.
Payments sit inside the wider commerce backend
Payments are one domain of the same model the rest of Vendure runs on. The total a payment collects is decided by catalogue and pricing, the order it settles belongs to the commerce backend, and store credit extends the layer as a native tender. The same model, database, and API surface sit behind all of it.
