Compliance

How we handle data, and what stays with each shop.

GatewayChanger decides which shop takes a payment. It never takes the payment itself and it never sees the card. This page says exactly what we receive, what we never receive, and what every shop that takes payments has to take care of itself.

Plain-language information, not legal advice.

Card details go straight to the shop

The payment form comes from the shop that charges and its payment provider. Card numbers, security codes and expiry dates never reach our servers.

We keep only what a ledger needs

Amounts, payment status, the card brand and last four digits, order references and the trace of each routing decision.

Each shop answers for its own payments

The shop that charges holds the merchant agreement and takes care of any licence or permission its business needs.

Where the card details go

From the customer to the shop that charges. Nowhere else.

The customer types their card into a form that belongs to the shop that charges — even when it sits inside another business’s checkout. We only hear the outcome.

The customer Checks out on the shared website and ticks who charges them.
The shop’s payment form Served by the shop that charges, with its provider’s secure fields.
Its payment provider For example Stripe or Adyen — runs 3-D Secure and takes the card.
The shop’s own account The money settles here, on the provider’s normal schedule.

The selling website never sees the card either — the form belongs to the shop that charges.
Our API has no field for a card number, a security code or an expiry date, and rejects anything that looks like one.
Customer checks such as 3-D Secure happen in the payment provider’s own flow.
Processor keys are typed into your browser and sealed with the shop’s own key — we only ever store ciphertext we cannot open.

How we treat data

What we receive — and what we never receive.

This is the whole list. If something is not on the left, our API does not accept it and our database has no place for it.

We receive — to route and to keep the ledger

The order — amount, currency, and the billing and shipping country.
The basket — product codes, quantities and prices, so rules can read them.
The decision — which rule matched, which shop charges and why others were skipped.
The outcome — status, amount, card brand, last four digits and the processor reference.
The consent — the sentence the customer agreed to, with its timestamp, IP address and browser.
The shop’s health — check-ins, plugin version and which payment accounts are connected.
Optionally — a one-way hash of the customer’s email address, never the address itself.

We never receive

Card numbers — not in a request, not in a log, not in the database.
Security codes and expiry dates — the API has no field for them.
The money — funds go from the customer’s payment provider to the shop that charged.
Readable processor keys — they are sealed in your browser for one shop; we hold ciphertext only.
Bank details of the shops — we run no payouts, so we never need them.

How we protect what we keep

Every connection is encrypted (HTTPS).
Every routing decision is signed; shops check the signature before they charge.
Calls between shops are signed and protected against replays.
Test and live data never mix — test shops can only route to test shops.
Logs are redacted, and changes to rules and shops are recorded with who made them.

Read this before you go live

The shop that takes the payment is the merchant.

Because the card details and the money go straight to the shop that charges, the duties that come with taking payments stay with that shop — not with GatewayChanger.

The website that sells stays responsible for its checkout, its customers and for showing the consent checkbox that names who charges.

Licences and permissions

Every licence, registration or permission its business needs, in every country it serves — for example for financial or investment advice, medical or cosmetic treatments, or trading second-hand goods.
Its payment provider knows

Its own merchant agreement, and a payment provider that knows how the account is used — including payments for orders sold on another business’s website.
The customer is told

Its name in the checkout, on the receipt and on the card statement, so the customer always knows who charged them.
After the payment

Refunds, chargebacks, receipts, invoices and the tax that goes with the payments it takes.
Card security rules

Its own card-security duties (PCI DSS). Its provider’s secure payment form keeps them small, but the provider decides what applies.
Its own terms

Terms and a privacy notice that say payments may be taken by a named partner business.

We do not give legal advice. Whether a licence or permission is needed depends on what is sold, where, and how the businesses are connected. Ask your payment provider and a lawyer in your country before you take live payments.

Before a shop can take payments for others, the dashboard asks you to confirm that its payment provider knows about it, that receipts and card statements name the shop that charges, and that this shop handles refunds and disputes — and records when you confirmed it.

Data protection

Privacy notice Data processing addendum

Roles: You are the controller for your customers’ data. We process the limited data your shops send us, only on your instructions.
Retention: Decisions and payments are financial records, kept for the life of your account plus the period set in the DPA. You can export them at any time.
Sub-processors: Listed in the data processing addendum, with notice before any change.
No selling, no training: We do not sell data, and we do not use your payment data to train anything.

The terms, privacy notice and DPA on this site are drafts published for review during early access and will be replaced by counsel-reviewed versions before general availability.

A question we have not answered here?

Ask us directly — we would rather write a straight answer than leave you guessing. Security reports are welcome at the same address.

Email us Read the FAQ