Frequently asked questions

Does GatewayChanger ever see card numbers?

No. The card form is served by the charging shop and, inside it, by that shop's own payment processor. The browser never posts card data to a gatewaychanger.com address, our API has no field for a PAN, a CVV or an expiry date, and our database has no column for them. What we receive is the card brand and the last four digits, alongside the amount, the status and the processor's reference.

Are you PCI certified?

No, and we will not say otherwise. GatewayChanger holds no PCI DSS Attestation of Compliance and does not appear on any scheme's list of validated service providers. The platform is designed so that cardholder data never enters it, which is what keeps it outside your cardholder data environment. What SAQ your shops complete is determined by your acquirer or a QSA looking at your actual checkout — see compliance.

Is it legal for one of my companies to charge for another?

It can be, and it is common in company groups — but it depends entirely on disclosure. Processing another entity's sales through your merchant account without your acquirer's knowledge is factoring, also called transaction laundering, and Visa and Mastercard prohibit it. Legitimate structures include disclosed group entities, marketplace or agency arrangements, and accounts opened for that purpose. We ask you to attest to the key points before a shop can act as a charger, and we store that attestation.

Who handles refunds and chargebacks?

The charging shop, because it holds the merchant agreement and the money moved through its account. The plugin puts the seller's order number on the charger's mirror order and the charger's references on the seller's order, so either side can find the other in one search. A refund started in the seller's admin is forwarded to the charger, executed at the processor, and reported back to both.

What happens if the charging shop is offline?

Every shop heartbeats every five minutes. Fifteen minutes of silence takes it out of routing and raises an alert, and your rule's next candidate — often "the seller charges itself" — takes the order instead. If a charge fails technically mid-checkout, the seller re-routes with that shop excluded. Card declines never fail over.

Do you hold or move money?

Never. Funds go from the cardholder to the charging shop's processor and settle into that shop's account. We produce the settlement report that tells you what one of your entities owes another; the transfer between them is yours to make.

What if GatewayChanger is down?

Routing decisions need us, so a checkout that has not been routed yet cannot proceed — the plugin then either hides the payment method or shows an error, as you configure. Everything after the decision is shop-to-shop: an in-flight payment completes without us, and the charger queues its outcome report and retries until we are back.

Can a shop be both seller and charger?

Yes, and most are. The roles are independent switches in the same plugin. A rule can also pick the seller itself as the charger, which uses that shop's own processor accounts through exactly the same code path.

Which processors do you support?

The processors are implemented in the plugins, not in our platform, because the credentials live in the shop. Version 1 ships a built-in test processor and Stripe. Others follow based on what customers actually ask for — tell us what you need.

Do you support subscriptions or saved cards?

Not in version 1. Both need card-on-file semantics at the charging shop and careful handling of scheme rules for merchant-initiated transactions. They are on the roadmap behind the first stable release of the plugins.

Which platforms do you support?

WooCommerce (WordPress), Magento 2 / Mage-OS, PrestaShop, OpenCart and Zen Cart. Every plugin covers both roles — seller and charger — and the last three are in build, each with its own status on its page: PrestaShop, OpenCart, Zen Cart.

The list is what it is for one structural reason. The charging shop has to serve its own card page — its own iframe, its own processor, on its own domain — because that is what keeps card data away from us and inside the shop that holds the merchant account. A platform we cannot install server-side code on cannot do that, so a fully hosted store can at best be a seller, and we would rather not ship half a plugin. Anything not on the list can integrate directly against protocol v1; it is the same contract our own plugins implement.

How do test and live environments differ?

They are completely separate: separate shops, keys, rules, decisions and transactions. A test shop can only route to another test shop, and the environment is baked into every key prefix and every grant. Test mode is never billed.

What does GatewayChanger cost?

Plans are priced by connected shops and nothing else: Growth covers up to 10 shops for $50 a month and Scale up to 100 for $100 a month, both billed yearly. Transactions and turnover are unlimited on every plan, and we never take a percentage of your volume. Test mode is free — the sandbox covers two test shops without any plan, and a paid plan gives test mode the same allowance as real payments. All the numbers are on the pricing page.

What happens to real payments if our plan ends?

Live route calls answer no_route with the code plan_inactive, so every plugin falls back to the behaviour you chose for "no shop available" — exactly as if no rule matched. Test mode keeps working, and the dashboard shows the problem under Needs you with the button that renews the plan.

Can I export my data?

Yes, whenever you want, at no charge: decisions, transactions and settlements as CSV or over the API. After cancellation your data stays exportable for 90 days.

How do I verify that a routing decision really came from you?

Every grant is signed with our Ed25519 key, and the public keys are published at https://gatewaychanger.com/.well-known/gatewaychanger.json. The plugins verify every grant; if you integrate yourself, the protocol page describes exactly how.

Something here is wrong or missing

Tell us: [email protected]. We would rather publish the answer than send it to one person.