What a Stripe integration gives you.
By handling auth and capture asynchronously and caching saved payment methods, you reduce friction at checkout and improve repeat-customer experience.
Settlement reports from Stripe reconcile directly to invoices in your ERP, with exceptions surfaced early so finance can close without manual rework.
Payment failures, chargebacks and refunds appear in named exception queues that customer service and finance can own, so issues are addressed before the customer escalates.
By tokenising payment methods with Stripe and never storing raw card data, you reduce audit scope and avoid re-certification overhead on platform upgrades.
Stripe handles cards, local methods and wallets with a single integration, so you can expand geographically without redesigning payment plumbing.
Where a Stripe integration earns its place.
If two or more of these are true, the integration usually pays for itself quickly.
Where off-the-shelf connectors fall short.
Vendor connectors are fine for simple cases. Here's where the real ones need more.
Stripe does not natively support partial-auth or split-capture scenarios where multiple captures are needed against a single auth. Orders with split shipments or dropship lines need custom orchestration logic in the commerce or OMS layer.
Stripe refunds are tied to the original charge. If your ERP issues a credit note that should credit a customer account but not refund the card, or if you need to refund only part of an invoice, you must define clear rules in the ERP and ensure the commerce or payment middleware enforces them.
Stripe Billing is a separate product from core Payments. If you need complex subscription rules, tiered pricing or usage-based billing, that logic sits outside Stripe core and must be orchestrated by your commerce or billing system.
Stripe accepts many local payment methods, but settlement terms, reconciliation categories and PCI compliance vary by method and region. Your ERP and finance team must own the mapping from Stripe payment method to nominal code and VAT treatment.
Stripe provides visibility into disputes and chargebacks but does not automatically respond or retry failed disputes. Customer service teams need a clear process to gather evidence and submit responses, and finance teams need to track disputed amounts separately.
Payment timing ambiguity (when capture happens, who decides, what triggers retry) is the most common source of silent failures and reconciliation drift in Stripe integrations; owning this decision upfront prevents months of chargeback surprises.
Where this integration sits in your estate.
Stripe holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.
One integration architecture, any storefront. Stripe connects through the same governed layer whatever commerce core you run.
- Payment intent creation and status
- Authorisation and 3DS challenge execution
- Capture and refund processing
- Payment token creation and storage
- Dispute and chargeback notifications
- Settlement reporting and reconciliation files
- Payment method display at checkout
- Tokenisation and vault token retrieval
- Capture trigger timing (at checkout or deferred)
- Refund request submission and failure handling
- Customer payment status and error messaging
- Saved-card management and deletion
Systems this integration usually sits next to.
Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.
- Adobe Commerce
- Magento Open Source
- Shopify Plus
- BigCommerce
- Other storefronts
- ERP (for deferred capture and refund coordination)
- OMS (for order-triggered payment capture)
- WMS / fulfilment (for shipment-triggered settlement reconciliation)
- Finance system (for cash ledger and reconciliation closure)
- Accounting software (for invoice and credit-note matching)
- Customer service platform (for dispute and refund communication)
- Fraud detection system (for rule-based auth decline)
Not sure if this works with your stack?
Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.
The data flows we wire.
Each flow has a direction and an owner. We agree both before a line of code is written.
How iWeb configures the integration around your business.
Same method on every integration. The decisions come before the code.
- 01Design auth and capture orchestration
iWeb defines whether Stripe captures at checkout (blocking checkout on failure) or after OMS confirmation (allowing inventory checks first). The chosen pattern is built into the commerce platform and validated in testing.
- 02Build 3DS and SCA handling
iWeb integrates Stripe's 3DS and SCA flows so the shopper completes the challenge in-context without redirecting to a separate page. Fallback flows for challenge failures are tested end-to-end.
- 03Set up reconciliation pipelines
iWeb builds ETL to pull Stripe settlement reports, parse transactions by captured amount and settlement date, and match them to ERP invoices. Reconciliation exceptions are routed to finance for review and closure.
- 04Manage tokenisation and vault lifecycle
iWeb configures Stripe tokenisation so saved cards are created at checkout, retrieved for repeat orders, and deleted when customers withdraw consent. Token refresh and expiry policies are built into the checkout flow.
- 05Create payment failure and exception queues
iWeb builds visible queues in your operations dashboard for failed captures, disputed charges, refund mismatches and other payment exceptions. Each exception includes the order, customer and required action so it can be resolved quickly.
Who owns what.
The single most important table in any integration. One system owns each field; everything else reads it.
Built this before
iWeb has designed payment capture orchestration, settlement reconciliation and exception handling for dozens of commerce estates. We understand where Stripe sits between the storefront, OMS and finance systems, and how to keep payment timing and refund workflows clear.
What we test before launch.
Every one of these is rehearsed before a customer ever sees the integration.
Common risks and where they bite.
We name these on day one. A risk written down is a risk you can plan around.
If capture is deferred to OMS or order acknowledgement, but the trigger is unclear or times out, the payment remains authorised but not captured. The authorization expires (typically 7 days) and the customer's account is never charged, breaking revenue recognition.
If 3DS authentication is required but the implementation does not gracefully handle challenge failures or timeouts, the shopper may see a blank screen or the order may be captured without proof of identity, exposing you to chargeback risk.
If your ERP issues a credit note but the Stripe refund is never triggered, or if the refund amount does not match the credit note, customers see conflicting messages and finance cannot close the transaction.
If Stripe settlement includes fees, reversals or refunds that your ERP does not account for separately, or if currency conversions are applied inconsistently, reconciliation drifts and month-end close stalls.
If Stripe dispute notifications do not reach customer service or finance, or if responses are not submitted before the deadline, you lose disputes by default and chargebacks accumulate.
If tokens are stored as raw Stripe IDs without versioning or if the token lookup logic is rebuilt during a replatform without migration, saved-card journeys fail silently and returning customers are forced back to full card entry.
Relevant services and sectors.
Common questions about Stripe integrations.
Should we authorise and capture at checkout, or defer capture?
Authorisation at checkout validates the card immediately and is simpler operationally. Deferred capture allows you to confirm inventory, validate the address or apply fraud rules before committing the payment. Choose based on your fraud tolerance and whether OMS order confirmation happens before payment. iWeb can build either pattern; the key is ensuring the capture trigger is clear and monitored.
How do we handle 3DS and SCA challenges?
Stripe's Payment Intent API embeds 3DS challenges directly in the checkout flow so the shopper does not redirect away. Your commerce platform must handle the challenge result (success, failed, or timed out) and either complete the order or show a clear retry path. iWeb builds this handling and tests the fallback paths so payment success rates remain high.
What happens if a payment capture fails?
If capture fails, the authorisation remains active (typically for 7 days). You must retry capture or the authorisation expires and the customer is never charged. iWeb builds a queue of failed captures that customer service can retry manually, or automated retry logic that respects Stripe's rate limits.
How do we keep saved cards secure without expanding PCI scope?
Stripe tokenisation stores the card data on Stripe's servers and returns a token that your commerce platform stores. Your commerce platform never sees raw card data, so PCI scope is limited to network security. iWeb configures tokenisation at checkout and ensures tokens are deleted when customers withdraw consent or close accounts.
How do refunds and credit notes reconcile?
Your ERP issues a credit note and triggers a refund request to Stripe with the original payment intent ID and refund amount. Stripe executes the refund and returns a confirmation. Your commerce or ERP system records the refund result. If the refund fails, the credit note and refund amount must match so finance can investigate. iWeb builds this reconciliation loop and surfaces mismatches.
What do we do if a customer disputes a payment?
Stripe notifies you of the dispute (usually within 10-14 days of the transaction). Customer service must gather evidence (proof of delivery, customer communication, refund proof) and submit a response before the dispute deadline (usually 21 days). If you do not respond, Stripe sides with the customer and you lose the funds. iWeb builds visible dispute queues and ensures deadlines are monitored.
How do Stripe settlement reports reconcile to our ERP?
Stripe settles funds to your bank account in batches (usually daily). The settlement report lists all captured payments, fees, refunds and chargebacks included in that batch. You must match the settlement report total to the bank deposit and then trace individual line items to ERP invoices. Refunds, fees and chargebacks often appear in separate line items, so your ERP mapping must account for them. iWeb builds ETL to automate this reconciliation.
What if we move to a new commerce platform? Do we lose saved cards?
Saved-card tokens belong to Stripe, not your old platform. If you tokenise with Stripe rather than storing tokens only on the old platform, tokens are portable to any new platform that connects to Stripe. However, if tokens were stored only in your old platform's database, they must be migrated or customers must re-enter cards. iWeb ensures tokenisation is done via Stripe from the start to avoid this problem.
How do we handle payments in multiple currencies?
Stripe supports multi-currency transactions. Your commerce platform sends the currency code and amount to Stripe; Stripe handles the charge in that currency. Settlement to your bank account includes any currency conversion fees. Your ERP must account for the currency and conversion separately. iWeb ensures the currency code flows through all systems and reconciliation accounts for conversion fees.
What payment methods should we enable beyond cards?
Stripe supports cards, Apple Pay, Google Pay, local methods (SEPA, iDEAL, Bancontact, etc.), digital wallets and bank transfers. Enabling more methods increases conversion but adds operational complexity (different settlement timelines, refund rules, local compliance). iWeb helps you prioritise by geography and customer segment, then builds the integration for each method.
How do we monitor payment health and spot problems early?
iWeb builds a dashboard showing daily payment volume, success rate, average time to capture, failed capture count, refund volume and dispute count. Alerts are triggered for unusual patterns (success rate drop, unexpected spike in failures, disputes above threshold). This visibility helps you catch problems before they grow.
What happens if Stripe is down? Can we still take orders?
If Stripe is unavailable, you cannot process payments. You can either queue orders for payment after Stripe recovers (risky for stock and customer experience) or gracefully disable checkout and show a message. iWeb builds monitoring so you know immediately if Stripe connectivity fails, and works with you to design a fallback (queue, manual payment, or temporary checkout closure).
How do we handle payment failures for subscription or recurring orders?
Stripe Billing handles recurring charges, but logic for what happens when a charge fails (retry schedule, customer communication, suspension) must be defined in your commerce or billing system. iWeb helps you design retry logic (e.g., retry 3 times over 5 days) and ensures failed charges trigger clear customer notifications.
Do we need separate integrations for different payment methods?
No. Stripe's API handles all methods through a single integration. You enable or disable methods in Stripe's dashboard, and the commerce platform displays available methods at checkout. iWeb builds a single integration that supports all enabled methods.
Projects with a similar shape.
A Brandbank and PIM connector built around automated product data and catalogue scope.
Product data enrichment streamlined across a larger, more scalable food retail catalogue.
A global parts commerce platform rebuilt around dealers, availability and aftermarket ordering.
Aftermarket parts ordering supported across dealer networks, availability data and global fulfilment.
A gardening commerce platform rebuilt around seasonal catalogue depth, search and checkout journeys.
Garden retail trading supported by stronger search activity and updated add-to-cart activity.