> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atum.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Credentials
> What 'credential' means if you come from cards or wallets
A **credential** on Atum is a signed statement about a participant. It travels **with** a [payment](/get-started/identity/verifiable-presentation) 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.
| | What it actually is | How it's checked |
| ------------------------ | ------------------------------------------------------- | ------------------------------------- |
| **Cards, ACH, and APIs** | A record stored in someone else's system | Lookup in that system |
| **Wallets** | The ability to sign from a specific wallet address | Signature on the transfer |
| **Atum** | A fact about a participant, bound to a specific payment | Signature on what you sent. No lookup |
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](/get-started/identity/verifiable-presentation) on that specific payment.
See [What is Atum ID?](/get-started/identity/overview). The signed statement is a [verifiable credential](/get-started/reference/glossary#verifiable-credential-vc). The binding to a specific payment is the [verifiable presentation](/get-started/identity/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](/get-started/reference/glossary#credential-payment-credential) vs [identity credential](/get-started/reference/glossary#credential-identity).
## 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](/get-started/support/who-owns-what).
| | Atum | You |
| ------------------------------------------ | ---- | --- |
| Issue **Known to Atum** | ✅ | — |
| Verify attached credentials at the gateway | ✅ | — |
| Onboard your customers | — | ✅ |
| Bring and attach third-party credentials | — | ✅ |
| Keep credentials current | — | ✅ |
Credentials go on a payment or a quote inside a [verifiable presentation](/get-started/identity/verifiable-presentation). Atum [checks](/get-started/identity/verifiable-presentation#if-a-check-fails) what you sent.
## Types today
Atum issues one type. Other types come from issuers Atum admits for your environment.
| Type | Issued by | What it says |
| ----------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **[Known to Atum](#known-to-atum)** | Atum | This signing account may operate on the network in a named role |
| Third-party | An issuer on the trust list for your environment | Named by that issuer. It might read as **KYB approved** or **customer onboarded** — the label is theirs, not Atum's |
There is no public menu of third-party names. [Email support@atum.xyz](mailto:support@atum.xyz) to get an issuer (and its types) added. Which types a perimeter requires is [Atum-side configuration](/get-started/concepts/policy-enforcement).
## 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](/get-started/concepts/authorization-and-counterparties), and with any third-party credentials you attach.
### A role, not a legal name
Unknown roles are rejected. The credential does not assert a company legal name.
| Role | Who | What it means |
| --------------------------------------------- | ----------------------------------------------------------------- | ----------------------------------------- |
| Payment provider (`psp`) | The **originator** — the organization submitting payment requests | Known to Atum as a payment provider |
| Settlement provider (`settler`) | An operator that submits price quotes and fulfills payments | Known to Atum as a settlement provider |
| Atum-operated service (`atumOperatedService`) | A service Atum runs | Known to Atum as an Atum-operated service |
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](/get-started/concepts/payment-intent) 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](/settle-payments/presenting-identity)
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](/get-started/identity/overview#enforcement-stages) — 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](/get-started/concepts/policy-enforcement). [Email support@atum.xyz](mailto:support@atum.xyz) to get an issuer added to the trust list for your environment.
## What to read next
How a credential gets onto a payment or a quote
Identity lists vs credential-type trust — who sets, who applies
Identity vs authorization
Who is answerable when software spends
Your onboarding vs Atum's checks at the gateway