Changelog

Dated, plain-language changes to the platform, the protocol and the store plugins. Breaking changes to the API or the shop-to-shop protocol are announced here before they take effect.

2026-10-26 — Route between your own payment accounts

Platform

• One shop can now use GatewayChanger on its own: your rules decide which of its own payment accounts charges each order — high-risk goods to your high-risk acquirer, everything else to Stripe, a backup account if one fails, limits per account. See Routing between your own payment accounts.
• A shop can take payments only for its own orders. It needs no card-scheme declaration, and we never send it an order from another shop.
• When a shop's own account fails during a checkout, the next of its own accounts takes over, instead of the whole shop being skipped.

Dashboard

• What this shop does now asks whether a shop takes payments only for its own orders or also for your other shops; only the second needs the declaration.
• New rule template Between a shop's own payment accounts: a label, an account and a backup account.
• The routing list warns when a rule could send another shop's orders to a shop that only takes its own.

Plugins (WooCommerce and Magento 1.8.0)

• When a shop charges its own order, the checkout shows no "processed by … on behalf of …" checkbox, and the plugin books no second bookkeeping order — the order the customer placed is the only one.

API

• Shops have own_orders_only. POST /api/v1/route accepts exclude_candidates (one account instead of a whole shop), answers consent.required: false when the shop charges its own order, and reports the candidate reason own_orders_only.

2026-09-25 — Refunds, chargebacks and failures that happen later

Platform

• Some things happen to a payment after the checkout: a refund that completes a day later, a capture the bank rejects after it looked done, a chargeback, a refund you make in your provider's own dashboard. They now reach your payments list, your statements and the shop that sold the order.
• The shop that took the payment reports its whole current state each time, numbered in order. A report that arrives late, twice or out of order can no longer count a refund twice or undo a newer change — it is kept in the payment's history, greyed, and changes nothing.
• A chargeback now takes only the disputed part off a statement, not the whole payment.
• If a provider completes a payment after the shopper was told it failed, or after they gave up, the shop gives the money back automatically and the payment is marked no order behind it; it never appears on a statement. Where the provider does not allow that (Worldpay), we alert you with the exact payment to refund by hand.
• A late failure only counts towards the safety switch when the provider itself had a technical problem — never for a declined card or an expired authorisation.

Dashboard

• Each payment account now shows where to register its payment notifications in the provider's dashboard: the address, the notifications to send to it and the secret to paste back, each with a copy button — and when the last one arrived. If the shop keeps refusing them for more than an hour, the account says so, Needs you lists it, and the button opens the field that fixes it.
• Needs you also lists a shop that gave up passing on a payment change after two weeks of retries, and payments whose outcome was still unknown after 14 days, each with a button to mark them as checked once you have compared them with your provider's dashboard.
• New alerts you can add under Settings → Notifications: a capture that failed after the money looked taken, a refund that failed, a chargeback won, and money that has to be given back by hand. A cancelled payment is available as a webhook to your own systems.

API

• New POST /api/v1/charges/{charge_id}/events for the shop that took the payment; transactions now carry disputed_amount, orphan and late. The older POST /api/v1/transactions/{id}/events keeps working, and is now accepted only from the shop that took the payment (or an organization key). Details in the API reference.

Plugins

• Receiving notifications from every provider arrives with version 1.5.0 of the WooCommerce and Magento 2 plugins and the matching PrestaShop, OpenCart and Zen Cart builds. Until your shop runs one, its payment accounts show no address and Stripe keeps using the one you registered before — the old Stripe addresses stay valid afterwards too.

Documentation

• Each store guide has a new Payment notifications section with the address pattern for that platform, replacing the Stripe-only webhook step. The Zen Cart address is now gwc_api.php/webhooks/{id}; gwc_webhook.php?processor={id} keeps working.

2026-09-25 — Eight more payment providers

Plugins

• A charger shop can now take payments with Adyen, PayPal (card fields and the PayPal button), Square, Mollie, Authorize.net, Airwallex, Checkout.com and Worldpay, as well as Stripe and Braintree. Each one takes the card in its own secure fields, so the card number never reaches either shop, and each one re-checks the amount with the provider before an order is marked paid. They ship in version 1.4.0 of the WooCommerce and Magento 2 plugins and in the current PrestaShop, OpenCart and Zen Cart builds.
• Checkout.com runs on the charger's hosted payment page only: Checkout.com does not allow its card form inside another site's page.
• Two partial refunds of the same amount are now always sent as two refunds. Before, the second could be mistaken for a retry of the first and never reach the customer.
• The nopCommerce plugin is withdrawn. It could not be built or tested alongside the others, and none of the new providers were available in it.

Documentation

• Which providers we support, which we decided against and why, is on each shop's payment accounts page in the dashboard.

2026-09-16 — Early access

Platform

• Architecture settled on the routing model: GatewayChanger decides which shop charges an order and with which processor, and never receives card data. The earlier vault-based design is withdrawn.
• Protocol v1 published: Ed25519-signed grants, signed shop-to-shop requests with nonce and timestamp replay protection, the charger REST API, the embed page and the hosted pay page.
• API v1 published: activation, heartbeat, routing, decision events, transactions and their events, plus the automation endpoints for shops, rules, decisions, transactions, settlements, webhooks and keys.
• Marketing site and this documentation set published.

Plugins

• WooCommerce plugin in development: seller gateway with consent and embedded card form, charger REST API, mirror orders, refunds, the test processor and Stripe.
• Magento 2 module in development: the same protocol on Luma checkout, with webapi charger endpoints and mirror orders through quotes, invoices and credit memos.
• PrestaShop, OpenCart, nopCommerce and Zen Cart plugins in build: the same protocol, the same field names and both roles, from one shared core. None of them has been verified against a live store yet — each guide carries its own status, and the date lands here when the first build passes the conformance suite.

Documentation

• Getting started, how routing works, consent and shop terms, a guide per store platform, the API reference, protocol v1, test cards and this changelog.
• Compliance states plainly what the platform touches, what it never touches, and what card-scheme disclosure duties fall on the shops.
• Terms, privacy notice and data processing addendum published as drafts for review.

Want to be told when something changes? Product update emails are opt-in from your account settings, and every entry here is dated.