Stripe Integrations

What Stripe collects in your store and which system owns each piece of data

Stripe handles the payment, not order management. In a well-designed integration, the online store owns the cart, the order and the customer; Stripe holds the card details and the outcome of each transaction; and the ERP owns the invoice, the accounting record of the payment and any credit notes. Drawing that line at the start avoids ending up with three different versions of whether an order has been paid.

A single integration can enable cards, wallets such as Apple Pay and Google Pay, and local payment methods depending on the buyer's country, such as SEPA Direct Debit or iDEAL in the Netherlands. That is what makes Stripe attractive for brands selling in several European markets: methods are switched on from the dashboard and checkout shows each buyer the ones that fit their country and currency, with no separate connector per method.

Each method requires a decision on how the order is handled. A card confirms instantly, whereas a SEPA debit takes days to confirm and can be reversed later. The store and the ERP need to tell an authorised order from one that has actually been paid before releasing it for fulfilment.

How we connect Stripe: API, webhooks and payment flow

Stripe is integrated through its REST API. The usual flow starts with a Payment Intent created on the store's server and confirmed in the buyer's browser using Stripe's payment components, so card details go straight to Stripe and never pass through your server. Depending on the case, we use the Stripe-hosted payment page or components embedded in the store's own checkout.

Reliable confirmation does not come from the browser returning to the store, but from webhooks: Stripe notifies you when a payment succeeds, fails, is refunded or is disputed. We process them idempotently, so a repeated notification never duplicates the order in the ERP, and we periodically compare the store's status with Stripe's in case a notification goes missing.

We start from Stripe's modules for Adobe Commerce (Magento) and PrestaShop when they cover the case, and build on the API when there are specific rules: B2B portals, partial payments, pre-orders or subscriptions tied to the ERP. On Shopify, the platform itself decides which gateways are available, so there we assess each case individually.

Strong authentication and customer-not-present charges with Stripe

In Europe, Strong Customer Authentication (SCA) means many card payments have to go through 3D Secure. With Stripe, that step is part of the payment flow: if the issuing bank requests authentication, the buyer completes it without leaving checkout, and if the bank exempts it, the payment goes ahead. What does need designing is what the customer sees when authentication fails and how they get back to their cart.

The trickiest case is merchant-initiated charges: subscription instalments, charges for an order finalised later, or replenishment agreed with a trade customer. For the bank to accept them without asking for authentication again, the card has to be saved with the right consent on the first payment. If the bank still requires it, the store must notify the customer and send them a link to authenticate.

Fraud rules also affect day-to-day operations: when a payment is held for review, the store keeps the order on hold until someone on your team approves it, instead of sending it straight to the warehouse.

Reconciling Stripe with the ERP, refunds and disputes

Stripe does not deposit each payment separately: it groups the payments for a period, deducts fees, refunds and disputes, and transfers the net amount to your bank account. For finance, that means the bank deposit does not match any single order. Reconciliation relies on the breakdown Stripe provides for each payout, which links every amount to its payment and, through the metadata the store attaches, to the order number.

We bring that breakdown into the ERP (SAP, Microsoft Dynamics 365, Oracle NetSuite, Odoo, Holded, a3ERP or Sage) to record the payments, the fees as an expense and the net amount against the bank. Refunds are triggered from the store or the ERP, executed in Stripe via the API and generate their credit note; disputes arrive by webhook so customer service can submit evidence in time.