Skip to main content
A credential on Atum is a signed statement about a participant. It travels with a payment or a quote. Anyone who receives it can check the signature. They do not call Atum to look you up, and Atum does not keep a private copy of your onboarding pack. That is a different object from what teams traditionally call “credentials.”
Attaching credentials is available, not required. You can submit and settle without them. When a corridor later requires a type, you attach it on the payment — you do not log into a portal and “set identity” once.

Credentials: cards, wallets, and Atum

Card platforms and wallet platforms both say “credential.” They do not mean the same thing. Wallet platforms and Atum both use a wallet key. That is not the same object:
  • Wallets: Signing is identity. The address is the person. There is no separate file about who that key is.
  • Atum: Signing still proves control of the funds. The credential is extra — a fact about that key (for example, Known to Atum as a payment provider), presented on that specific payment.
See What is Atum ID?. The signed statement is a verifiable credential. The binding to a specific payment is the verifiable presentation.
x402 and MPP also use “credential” for a signed payment authorization — the PAYMENT-SIGNATURE header (x402) or Authorization: Payment header (MPP). That is not this page. See payment credential vs identity credential.

Shared responsibility

Atum issues the network-level credential and verifies what you attach. You own customer onboarding and any third-party credentials. That split is operational, not a shared legal obligation — see Who owns what. Credentials go on a payment or a quote inside a verifiable presentation. Atum checks what you sent.

Types today

Atum issues one type. Other types come from issuers Atum admits for your environment. There is no public menu of third-party names. Email support@atum.xyz to get an issuer (and its types) added. Which types a perimeter requires is Atum-side configuration.

Known to Atum

Known to Atum is the credential Atum issues to participants today. It means this signing account is allowed to operate on the network in a named role. It is not:
  • A compliance statement
  • Approval of a payment
  • A screen of the wallet that is sending funds
  • A check of your customer’s legal identity
Those stay with you, with authorization, and with any third-party credentials you attach. Unknown roles are rejected. The credential does not assert a company legal name. API fields use psp and settler. In these docs, that is payment provider and settlement provider.

Bound to the signing wallet

Known to Atum is about the wallet that signs the payment request or the quote. It is not issued to an API client, merchant ID, or domain.

Provided during onboarding

You do not mint Known to Atum. There is no dashboard button and no public issuance API. Atum issues it when it onboards you as a participant:
  • Payment providers — for the originator account you sign requests with
  • Settlement providers — for the account your agent signs quotes with. See Present identity with a quote
A testnet credential is not valid on mainnet, and the reverse is also true. Do not reuse one across environments.

Third-party credentials

If a payment needs more than Known to Atum — for example a KYB approved credential from a vendor Atum has admitted — bring that issuer’s credential. Atum adds the issuer to the trust list for your environment; the issuer, not Atum, issues the credential, names the type, and holds the documents behind it. You attach the credential inside your presentation. At the gateway, Atum verifies:
  • The issuer is on the trust list for that environment
  • The credential is about the participant presenting it (you cannot attach someone else’s)
  • The signature is valid and it has not expired
What happens on a failed check depends on your environment’s enforcement stage — today, most partners are on audit or permissive, where a failure is logged and the request still proceeds.
Which types are required, and which issuers are trusted, is Atum-side configuration today — see Policy enforcement. Email support@atum.xyz to get an issuer added to the trust list for your environment.

Verifiable presentations

How a credential gets onto a payment or a quote

Policy enforcement

Identity lists vs credential-type trust — who sets, who applies

What is Atum ID?

Identity vs authorization

Know Your Agent

Who is answerable when software spends

Who owns what

Your onboarding vs Atum’s checks at the gateway