Why authorization exists
A blockchain transfer has no “hold” or “ask the recipient first.” Enterprise payments need counterparty consent before value moves — especially when the recipient is a registered merchant or beneficiary PSP.The handshake (roadmap)
Originator PSP and counterparty PSP coordinate through Atum:- Originator: my customer wants to pay your customer this amount on these terms
- Counterparty: accepted — this merchant and amount are allowed
- Compliance and policy checks run on both sides during this step
What exists today
On public testnet, you can submit and settle payments without a separate counterparty authorization step for basic integration. Counterparty authorization APIs exist in the protocol (POST /v1/payments/authorizations) and are exercised in internal environments — not required for the CLI quickstart.
Custodial vs self-custodial
Identity is a different question
Atum ID answers who is acting (and what has been attested about them). Authorization answers whether this payment may proceed — funds, policy, and, when enabled, counterparty consent. A Known to Atum credential does not authorize a transfer. A signed payment request does not, by itself, replace identity credentials. Choosing which settlement providers may fulfill a payment is also not this handshake. That is an optional identity list on the payment request, set by the originator. Recipient consent (this page) is a separate step.Relation to settlement
When enabled, authorization completes before settlement is initiated. Settlement follows the model in Atum payment lifecycle.Next steps
- Who owns what
- Policy enforcement — identity lists vs credential-type trust
- Payment request — how you set the identity list
- What is Atum ID?
- Know Your Agent
- Participants