Skip to main content
Talk to an expert
TechnologyPayments

Payments integrations for ecommerce.

Payments is the part of the storefront that turns intent into money. iWeb integrates payment providers, B2B account terms and alternative tenders into ecommerce, with PCI scope kept tight and reconciliation kept honest.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
Contents · 6 sections
  1. 01Common problems and patterns.
  2. 02Selected case studies.
  3. 03How this system fits next to commerce, PIM and ERP.
  4. 04Questions we get asked.
  5. 05Clients we build for.
  6. 06Where this fits in the wider estate.
01 · Common problems and patterns

Common problems and patterns iWeb sees.

Card payments
Card providers integrated with hosted fields or redirect, with PCI scope kept tight.
B2B account terms
Account customers paying on terms, with credit checks and statement reconciliation governed by the ERP.
Alternative tenders
BNPL, wallets and bank transfers where the customer base actually uses them.
Refunds
Refunds against the original tender, with reconciliation back to the ERP and the OMS.
3DS and SCA
Strong customer authentication handled correctly, with friction kept proportionate to risk.
Reconciliation
Payment events reconciled against orders and invoices, with breaks alerted rather than absorbed.
Saved cards and tokenisation
Tokenised cards for repeat purchase and subscriptions, with PCI scope kept off the storefront.
Multi-currency and territory
Currency conversion, settlement currency and per-territory tender mix designed against the actual customer base.
Subscription billing
Recurring billing, dunning and retry strategy for subscription estates, with reconciliation back to the ERP.
Fraud and risk
Risk scoring at checkout tuned per channel, reviewed against actual chargebacks rather than vendor defaults.
Operational monitoring
Payment success rates, declines and provider outages monitored as a first-class signal, not via end-of-month reports.
Honest tender-mix read
Card, account terms, BNPL, wallets and bank transfers chosen against the actual customer base and geography, not assumed from a vendor demo. Provider choice follows tender mix, not the other way around.
02 · Related work
03 · Integration and operational context

How this system fits next to commerce, PIM and ERP.

Where this system lives in the estate
The integration boundary with commerce, PIM, ERP and operational systems named, versioned and observable, not implied by a connector setting.
Catalogue and PIM separation
Catalogue truth lives in PIM. This system reads from PIM rather than maintaining a parallel product record that drifts away from it.
ERP boundary and commercial data
ERP still owns price, stock and accounts. This system orchestrates around the ERP rather than replacing it; the boundary is the design decision.
Storefront and customer surface
How customers see the output of this system on the storefront (search, content, order state, payments) governed with the same rigour as the commerce platform itself.
Real-time vs scheduled sync
Read paths cached at the storefront boundary, writes posted through monitored queues, reference data refreshed on a defined cadence tuned to ERP and PIM load.
Multi-territory and locale handling
Locale-aware behaviour wired in early, not bolted on per project. Translation, currency and per-market rules belong inside the platform rather than the storefront.
Governance and editorial workflow
Approval, completeness and audit workflows that match how the merchant actually edits, releases and runs the estate day to day.
Operational telemetry
Throughput, failures, queue depth and reconciliation reports surfaced as visible signals with on-call ownership, not as silent backlog.
AI under governance
AI features (query understanding, attribute mining, recommendations) scoped to where they earn their place, with decision logs and override controls.
Long-term support and incident response
Releases, incidents and upgrades governed under the same operating model as the wider estate, with a written runbook the on-call team can act on.
Takeover and stabilisation
Inherited builds audited, stabilised and documented before any larger change. The first month on support is deliberately conservative on change.
Honest vendor independence
iWeb names the right tool for the brief rather than the closest partner badge. Decisions are written down with their trade-offs, not assumed.
04 · Questions we get asked

Questions we get asked.

When does payment choice actually move the dial?

When the tender mix is wrong for the customer base: trade accounts forced through card-only checkout, BNPL absent where the basket warrants it, or refunds hitting the wrong tender. The choice is a function of operation, not fashion.

Where does payments sit relative to commerce and ERP?

At the storefront for capture and at the ERP for reconciliation. The ERP owns the finance record; the storefront passes the event through. Refunds reconcile back through the same path.

Which commerce platforms does iWeb integrate payments on?

Payments work iWeb has shipped sits mostly on Adobe Commerce and Magento. The integration pattern (hosted fields, 3DS, reconciliation back to ERP) is platform-agnostic and applies on other commerce platforms where the provider supports them.

How is PCI scope kept tight?

Card data is handled by the provider through hosted fields or redirect. PAN data does not touch the storefront. Scope is kept tight by design rather than by retrofit.

How do B2B account terms fit alongside card payments?

They sit side by side. Account customers pay on terms with credit and statement reconciliation governed by the ERP; retail customers pay by card. Both flow through the same checkout.

Which payment providers does iWeb integrate?

The decision is client-led. iWeb has integrated Adyen, Stripe, Worldpay, PayPal and account-on-terms flows on commerce platforms, with the same pattern: hosted fields, 3DS, reconciliation back to the ERP.

What are the typical risks in a payments project?

Reconciliation gaps between provider and ERP, refunds routed to the wrong tender, and PCI scope quietly creeping back in. iWeb names those failure modes in scoping rather than at launch.

How do payments connect to ERP for reconciliation?

Payment events flow through to the ERP so the finance record stays the source of truth. Refunds reconcile through the same path. The storefront does not own finance state.

Can iWeb take over an existing payments setup?

Yes. The team reads the existing provider configuration, reconciliation flow and incident history first, then writes down what to keep, stabilise or change.

Can multiple payment providers run side by side?

Yes. Routing rules at checkout direct each transaction to the right provider by tender, market or risk profile. Account customers on terms sit alongside card payments through the same checkout.

How is PCI scope kept tight on the storefront?

Card data is handled by the provider via hosted fields or redirect. The storefront does not see PAN data; scope is kept tight by design rather than retrofitted.

How are payment success rates and provider outages monitored?

As a first-class operational signal, not via end-of-month reports. Declines and provider incidents are alerted in production with a runbook for triage.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Got a brief on payments?

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see all technologies →