GoCardless payment integration for ecommerce

iWeb maps the customer's country, payment method preference (direct debit, card, bank transfer) and order currency to the right GoCardless endpoint. SEPA, Bacs, ACH and other schemes are selected based on customer location and configured rules. Validation (e.g. IBAN format, account-holder name) is enforced before submission to reduce failed charges.

iWeb ensures that order cancellation signals reach GoCardless immediately and prevent capture. If capture has already begun, iWeb submits an instant refund to reverse the charge. Idempotency keys prevent duplicate refunds if the cancellation signal is retried.

iWeb pulls daily settlement reports from GoCardless and reconciles each transaction against ERP invoices. Failed captures, chargebacks and forex variance are identified and routed to a named exception queue with full order and customer account context. Finance teams resolve these without manual lookup.

Yes. iWeb tracks the customer currency, GoCardless settlement currency and the forex rate applied. Forex variance per transaction is calculated and allocated to the right GL code. Settlement delays are monitored so forex exposure can be forecasted and hedged if needed.

iWeb integrates GoCardless recurring-payment events with a configurable retry strategy. Failed recurring payments trigger escalating notifications (email, SMS) to the customer and a dunning workflow. If payment recovers, the subscription resumes; if not, it is suspended or cancelled based on policy.

iWeb maintains a chargeback queue linked to the original invoice and customer account, even after the invoice is closed in the ERP. Finance and customer service can view the full transaction history, dispute reason and previous customer contact. A resolution workflow (refund, dispute counter, or contact) is triggered based on the case outcome.

GoCardless only processes order-level refunds. iWeb maps partial cancellations (e.g. one fulfilment house ships, another cancels) to a single order-level refund and tracks what was actually delivered. Finance and operations teams know which lines shipped and which were refunded without confusion.

iWeb monitors payment authorisation, capture, settlement and chargeback events in real-time. Failed captures, pending settlements beyond a threshold, duplicate refunds and exception queues trigger alerts. A dashboard shows payment throughput, failure rates and reconciliation status.

Settlement timing varies by scheme (SEPA 1-2 days, Bacs 3-5 days, ACH 1-2 days). iWeb does not assume same-day settlement; a buffer window is configured so reconciliation does not flag pending transactions as errors. Forex settlement may add additional lag.

Yes. iWeb uses idempotency keys on every payment intent, refund and settlement submission. Duplicate webhook events or retried API calls do not result in duplicate charges or refunds.

iWeb configures a fallback behaviour: either reject the payment and ask the customer to retry, or queue the payment for batch retry once GoCardless recovers. No unpaid orders are left in an ambiguous state. The chosen strategy is tested before launch.

GoCardless holds customer payment method tokens. If you replatform, the token reference is migrated to the new system (if the new platform supports GoCardless) or customers are asked to re-authorise. iWeb plans this migration in advance and tests it without losing payment history or subscription continuity.

Finance and customer service own the refund decision. iWeb surfaces the dispute in a queue with full order, customer and chargeback reason context. Once the decision is made, iWeb routes the refund instruction to GoCardless and tracks the settlement.

Yes. If you have multiple ERPs (e.g. by region or brand), iWeb can route payments and settle by ERP entity. Each ERP receives invoices and settlement records for its own transactions, and reconciliation happens at the entity level.