Atum has only one payment shape. Anything else is just a different input.

Insights Luis Ortiz Read Time: 6min

You ask someone if Atum can handle cross-border payments. Yes. Merchant acceptance? Also yes. Agent payments, payouts between institutions, payments a smart contract kicks off? Yes, yes, the answer is yes. By the end, it starts to sound like Atum paid this person to dodge your questions.

We assure you, we didn’t.

Under every payment use case, the payment itself follows the same shape. The only difference is who’s paying, who’s receiving, and what triggered the payment in the first place.

Atum lets you pay from the chain and currency you already hold, and land in the exact currency and chain your recipient expects. Getting from one to the other always runs through the same four things: authorization, a quote, settlement, and verification.

Same shape, different origins

Cross-border payments and remittances. Your user holds tokenized dollars on one chain and needs to pay someone who wants a different currency on another. They authorize what’s already in their wallet. A settlement operator quotes and delivers to your destination. Signing costs nothing on-chain, and the receiver ends up with an exact, pinned amount. Same payment shape, but the trigger is a person sending tokenized money abroad.

Merchant acceptance. You get paid in the currency you keep books in, on the chain you already operate on, and stop caring what the customer spends. You set the destination asset and the exact amount you must receive. A settlement operator fulfills your side first, then draws from the settlement vault on the source side once fulfillment is verified. Neither of you ever has to hold the other’s asset. Same payment shape; the trigger is a merchant getting paid in the asset they actually run on.

Agentic commerce and pay-per-use APIs. Software that buys things, whether that’s an agent, a crawler, or one service calling another. You gate a route behind 402 Payment Required with machine-readable terms, and the buying program reads them, signs, and retries. Two protocols carry this today: x402 routes through a keyless facilitator that hands off to Atum, and MPP has no facilitator at all and verifies inside your own process. One honest caveat: this flow checks the signature, not who is behind it. Proving an agent’s identity, or that a person delegated the authority to spend, is separate work and not part of it today. Same payment shape; the trigger is software hitting a paid endpoint.

Payments between institutions. Some payments can’t start until the receiving institution approves them. The originator asks for counterparty authorization, the beneficiary’s registered service answers synchronously before anyone is asked to quote, and its signed decision rides along with the payment. Authorized, declined and timed out are three different outcomes, not one generic failure. Same payment shape; the trigger is an institution’s approval before value moves.

Programmable payments triggered on-chain. A contract emits a payment intent and something has to carry it out in the real world. A small service watches for the event, builds the request, signs it with a key and submits it. The chain decides when to initiate. The same workflow runs: authorize, quote, settle, verify. Same payment shape; the trigger is an on-chain event instead of a person or simple API call.

Same shape, different roles

Pluggable verification. This is the one nobody expects. The payment request defines who has to confirm a payout, and the settlement vault won’t release without that party’s signature. Verification is a step in the same workflow shape, not a separate product, and it does not have to come from Atum. It can come from an audit firm, a custodian, or an insurer. Settlement operators say up front which verification services they will accept.

Independent settlement. Settlement is a business in itself, not just part of the plumbing. If you already hold inventory across chains, you can quote on the corridors you pick, at prices you set, and fulfill what you take on. Atum provides the infrastructure and interfaces you connect to; you run the operation – your servers, your liquidity, your keys, your pricing. You’re an independent participant rather than our contractor, which also means you carry the obligations that come with that.

The unglamorous part

All of this lives or dies on who’s allowed to stand in the middle, so those controls are part of the payment from the start – not layered on as an afterthought once money is already moving.

A single request can pin exactly which settlement operators are eligible to fulfill it –and that’s enforced against a cryptographically recovered signer rather than a claimed identity. Operators have to be admitted to the network; they can’t just show up and start handling payments. The receiving institution can be required to authorize before anyone is even asked to quote. And every payment request is screened before value moves, source and destination addresses both, with no amount threshold below which the check is skipped and no participant exempt from it.

Worth saying plainly, because this corner of the industry is sloppy about it. None of that makes a payment compliant on its own, and none of it moves anyone’s legal obligation onto Atum. Atum gives participants the controls and the information the flow needs. Participants stay responsible for the rules that apply to them.

Don’t take our word for it

We ship example apps you can run yourself. One makes a payment with real testnet funds, then checks both chains to prove it happened, the funds leaving on one side and arriving on the other. If those transactions aren’t there, the test fails instead of quietly passing. Clone one and watch the money land.

So what does yours look like?

One shape, and this is only what we know about today. It’s a snapshot rather than a boundary, and we expect it to be out of date within a year because it’ll be too short. So the useful question was never whether Atum handles your use case. It’s what your payment actually looks like? What the payer holds, what the receiver has to end up with, and who’s allowed to stand in the middle. Answer those three, and you’ve described an Atum payment.

Subscribe to Atum

Stay updated with the latest market trends, product updates, and expert analysis.