We can't lose your money. We never hold it.
Most payment risk comes from one place: a processor holding your funds. PYMSTR is built so that never happens. Money settles straight to your own wallet, you hold the keys, and we control no contract. The safest pot of money is the one that does not exist.
The risk we engineered out.
We never hold your money
Payments settle straight from the customer wallet to your wallet in a single on-chain transaction. PYMSTR never receives, holds, routes, or controls the funds. There is no balance on our side to freeze, delay, or lose.
Nothing to drain
Custodial processors pool merchant money in their own wallets, which is exactly what has cost the industry hundreds of millions in hacks. We engineered that risk out: there is no pot of customer money here, so there is nothing for an attacker to take.
No keys, no switches
PYMSTR controls no contract. No admin key, no pause, no blacklist, no redirect. The most we can do is reject a payment that does not match the recipients and amounts you configured.
A bug cannot move your funds
Because the customer wallet signs the exact, validated transfers, a software error on our side cannot move or lose money. The worst case is a payment that does not go through, which is simply retried.
The entire on-chain path is public code we did not write, each piece independently audited. There is no PYMSTR smart contract in the flow to trust or to break.
ERC-4337 account abstraction
The smart-account standard the customer wallet runs on. The on-chain EntryPoint enforces that only the buyer-signed transfers execute.
Pimlico ERC-20 paymaster
Lets the customer pay gas in the stablecoin itself. It cannot drain the account or redirect funds.
USDC and USDT token contracts
The stablecoins themselves, issued and maintained by Circle and Tether.
The layer around the rail.
Signed webhooks
Every webhook is signed with HMAC-SHA256 (X-Pymstr-Signature) and carries a timestamp with a 5-minute tolerance, so you can verify it came from us and reject replays.
Scoped API keys
API keys support IP allowlisting and are rate limited. A leaked key is constrained to the addresses you approve.
Hardened sessions
Sessions live in Redis with sliding expiry, tokens are kept in memory rather than local storage, and repeated failed logins lock the address out.
Locked wallet address
Once your smart-wallet address is set it cannot be changed, which closes off account-takeover by address swap.
Minimal data
We hold no funds and minimal data. Webhook payloads are reconstructed on demand from the payment record rather than stored.
Verify everything on-chain
Every payment carries its on-chain transaction hash, so you can independently confirm what happened against a public ledger.
The keys are theirs, not ours.
A customer signs in with their normal Google, Apple, or email login and a wallet is created for them automatically through Web3Auth, split into key shares that PYMSTR never holds. We cannot touch the funds, and recovery never depends on us.
- With MFA enabled, the customer can recover their wallet with no dependency on PYMSTR or Web3Auth.
- Customers can bring their own wallet instead, such as MetaMask or a hardware wallet.
- Merchants can route funds straight to their own custody, for example Gnosis Safe or Fireblocks, so the money never rests in a PYMSTR-created wallet at all.
PYMSTR is payment infrastructure, not a processor that handles your customers' money. You hold the relationship with your customers, so screening stays with you, and we make that practical: every payment carries its on-chain transaction hash, so you can screen the payer with your own provider (Chainalysis, Elliptic, TRM) on your own rules, before or after payment.
How that responsibility is allocated is set out in the Merchant Agreement. For the architecture behind all of this, see how non-custodial works.