Skip to main content
Most payment security asks you to trust that the processor’s systems are intact. This one doesn’t.

​
The threat

Suppose an attacker fully compromises our database and rewrites your payout address to theirs. On a conventional processor, that’s the end of the story — the checkout renders whatever the database says, and customers pay the attacker. We designed so that attack fails.

​
The mechanism

You pin your payout address in the embed code on your own site:
That value lives in your HTML, which our database cannot reach. Before showing any payment option, the checkout does this:

Read the chain

The browser calls the on-chain registry to get your attested payout address. That attestation was written by your wallet and can only be changed by your wallet.

Recompute the address

From that chain-read value, the browser recomputes what your pool address must be — the same deterministic derivation the contracts use.

Compare

If the recomputed address differs from what our API served, something is wrong.

Refuse

The checkout enters a terminal state, hides the payment address, and tells the customer not to pay.
The key property: because step 2 derives from the chain-read value rather than the served one, an attacker who consistently rewrites both the recipient and the pool address in our database still fails. The derivation anchors to the chain.

​
Why the integrity hash matters too

The verification runs in JavaScript we serve — so what if that JavaScript were tampered with? The integrity attribute pins its exact hash. If the file we serve differs by a single byte, the browser refuses to execute it at all. Tampered code fails closed rather than running altered.
Keep both integrity and settlementAnchor. Removing either silently removes a protection that exists specifically for you. Neither affects how the checkout looks or behaves normally, which is exactly why they’re easy to drop during a refactor.

​
Honest limits

We won’t overstate this. The conditions under which it holds:
Without settlementAnchor in your embed, the checkout shows an unverified badge and does not block. The protection is opt-in per merchant because it depends on something only you can provide.
A total compromise of our served code is mitigated by the integrity pin, not eliminated. Different threat, different (weaker) guarantee.
Both connect and deposit. An older atomic payment path exists for legacy integrations and is outside this guarantee.
The anchor check is EVM-only today. TRON payments settle correctly but do not carry this specific verification.
A third-party security audit is a mainnet gate and has not completed. Roadmap.
We describe this as a mechanism with conditions, never as “unhackable.” Any vendor who tells you their system cannot be compromised is telling you they haven’t thought about it carefully.

​
Checking for yourself

Verify page

Every deployed contract, per chain, with explorer links.

Read your own pool

Call recipient() on your pool address on any block explorer. It should be your payout address, and you should be unable to change it.