Compliance

What we touch, what we never touch, and what stays your responsibility

Routing an order to a different company's payment account is a legitimate, common arrangement — and it has rules. This page states plainly what GatewayChanger does, what it deliberately cannot do, and what you must have in place before you switch on live routing.

Information, not legal advice. Your acquirer, your PSP and your own counsel decide what applies to you.

The data boundary

Everything on this page follows from one architectural choice: card data never enters our systems, because there is no path into them for it.

What we receive and store

Amount in minor units and ISO-4217 currency
Status: authorized, captured, failed, refunded, disputed
Card brand and last four digits — never the full number
Processor name and processor reference (for example a Stripe pi_… id)
Billing country, and an optional SHA-256 hash of the customer email
Shop ids, order references on both sides, and the matched rule
Consent text version, its hash, timestamp and IP as evidence
Heartbeats: which shop is online, with which processors and currencies

What never reaches us

The primary account number (PAN) — in full or in part beyond first six and last four
The CVV or CVC — it is never persisted anywhere in the flow
Expiry dates, cardholder names, magnetic-stripe or chip data
Your processor credentials: secret keys, webhook secrets, API passwords
Money. We never hold, route or settle funds — your processors do
The customer’s payment session with the processor, including 3-D Secure

A raw-card relay mode exists in the protocol specification for processors that require a PAN server-to-server. It is switched off, unimplemented, and would put both shops in a much larger PCI scope — so it will stay an explicit, documented opt-in.

PCI DSS — the honest version

What we do not claim

We are not “PCI certified”

GatewayChanger holds no PCI DSS Attestation of Compliance and does not appear on any card-scheme list of validated service providers. We will not tell you otherwise, and if you see that claim anywhere about us, it is wrong.

What is true by construction

Designed to stay outside the CDE

The platform is designed so that no cardholder data reaches it: our API has no field for a PAN, a CVV or an expiry date, and the browser never posts card data to a gatewaychanger.com origin. A system that cannot receive cardholder data is designed to sit outside your cardholder data environment.

Who decides

Your acquirer, not us

Which SAQ you complete, and whether your implementation qualifies, is determined by your acquirer or a QSA looking at your actual checkout. We give you the architecture and the documentation to make that conversation short.

Where each participant stands

PCI position of each participant in a routed payment
Participant	Sees card data?	Typical position
GatewayChanger	No — by design	Technical service provider outside the cardholder data environment; stores brand and last four only.
Seller shop (A)	No	Card fields live in an iframe served by the charger, and inside that the processor’s own hosted fields. SAQ A-eligible when implemented as documented.
Charger shop (B)	No raw PAN	Uses its processor’s client-side tokenisation inside the embed page; its server handles processor tokens, not card numbers. SAQ A-eligible when implemented as documented.
Processor	Yes	The regulated, PCI-validated party that actually handles the card. Its credentials never leave the charger shop.

The protocol also describes a raw-card relay mode for processors that only accept a PAN server-to-server. It is switched off and unimplemented. Turning it on would move both shops into a far larger PCI scope, so it will always be an explicit, documented opt-in — never a default, never a silent update.

PSD2 — we are a technical service provider

GatewayChanger does not execute payment transactions, does not issue or acquire payment instruments, and at no point comes into possession of the funds being transferred. We answer a routing question and keep a record of what happened afterwards.

That is the position PSD2 describes for technical service providers supporting the provision of payment services without entering into possession of funds (Directive (EU) 2015/2366, Article 3(j)). It is our reading of our own architecture, not a determination by a regulator, and it is the licensed processors and acquirers in the flow that carry the regulated obligations.

Strong customer authentication and 3-D Secure happen inside the processor’s own flow, in the charger’s page. We neither perform nor exempt them.
Funds move from the cardholder to the charging shop’s processor and settle into that shop’s account. We never sit in that chain.
Refunds, chargebacks and disputes belong to the charging shop, which holds the merchant agreement.
We hold no payment account, no e-money and no client funds.

Who is responsible for what

GatewayChanger: Routing decisions, signed grants, the ledger, alerts, the dashboard, the plugins and this documentation. Availability of the routing API.
The seller shop: The customer contract, the goods, the checkout consent, its own terms of service, the customer order and customer service.
The charger shop: Its merchant agreement, its processor credentials, the charge itself, receipts and descriptors, refunds, disputes, and telling its acquirer what it processes and for whom.
Your organization: Choosing which shops may charge for which, keeping the arrangement legitimate and disclosed, and the tax and invoicing between your entities.

Read this before you go live

Card-scheme rules on charging for another entity

Putting another company's sales through your own merchant account without your acquirer's knowledge is called factoring or transaction laundering. Visa and Mastercard prohibit it, and the consequences fall on the merchant account, not on the software: fines, termination, and placement on the MATCH list.

Arrangements that are normally fine

Companies in one group, where the acquirer knows which legal entities are being processed for and the receipts say so.
A marketplace or agency arrangement with a written contract between the entities.
A processor account opened for exactly this purpose, with the arrangement described in the application.
A payment facilitator or marketplace model operated under your PSP’s own programme.

What you must be able to say “yes” to

My acquirer or PSP knows that this shop processes payments for the other entities I have listed.
The descriptor and the receipt name the entity that actually takes the payment.
The customer is told at checkout who charges them, and agrees to it.
Refunds and disputes are handled by the charging shop, which can reach the customer’s order.
There is a written agreement between the selling and the charging entity.

When you add a shop in the charger role, GatewayChanger asks you to attest to exactly those points and stores who accepted them and when. It is a deliberate speed bump: we would rather lose a signup than help someone build transaction laundering by accident.

The customer is told, in the checkout, which company will take their money and on whose behalf. It is a required checkbox, not a line in a footer, and the sentence carries the real legal names and the real amount.

When it is accepted we store the exact text, its SHA-256 hash, the version, the timestamp and the IP address — on the seller's order and again on the charger's mirror order. A dispute about “I never agreed to pay that company” is then a two-minute lookup instead of an argument.

Consent and shop terms →

Stored on both orders

{
  "text": "I agree that my payment of €24.99 is
           processed by Shop B Ltd on behalf of
           Shop A GmbH.",
  "version":     "2026-09-16",
  "text_hash":   "sha256:7b41c0…",
  "accepted_at": "2026-09-16T10:04:11Z",
  "ip":          "203.0.113.24",
  "user_agent":  "Mozilla/5.0 …"
}

Your seller shop's terms of service must also state that payment may be processed by a named affiliated company. The plugin links your terms page from the consent line.

Roles

You are the controller for your customers’ data. GatewayChanger is a processor for the limited data your shops send us, and acts only on your instructions.

Personal data we hold

Billing country, an optional SHA-256 hash of the customer email, the consent IP and user agent, order references, and the card brand with the last four digits.

Retention

Decisions and transactions are kept for the life of your account plus the period in the DPA, because they are financial records. You can export or request deletion of anything that is not.

Sub-processors

Listed in the data processing addendum, with notice before any change. We do not sell data, and we do not use your transaction data to train anything.

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

Security measures in the product

Signed decisions

Every routing decision is an Ed25519-signed grant, bound to one charger, one amount, one currency and a 30-minute expiry. Our public keys are published so shops can verify offline.

Signed shop-to-shop calls

Timestamp, nonce, method, path and a hash of the exact body, signed by the caller’s key. Replays are rejected for ten minutes; skewed clocks are rejected outright.

Key ownership

Each shop generates its own key pair; the private key never leaves the shop. Rotation is supported with a seven-day overlap.

Isolation of environments

Test shops can only route to test shops. Keys carry their environment in the prefix, and a live grant is invalid in test.

Least data

The API rejects fields it does not need. There is no PAN column, no CVV storage anywhere, and logs are redacted by design.

Audit trail

Who changed which rule, when a shop was added or paused, when an attestation was accepted, and the full trace behind every decision.

Questions we have not answered here?

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

Email us Read the FAQ