Masking of sensitive data
The API distinguishes between data that identifies an account and data that would allow using it. The former stays readable because it is needed to operate; the latter is masked as soon as it leaves the flow that needs it.
Cards and CLABEs are treated differently
| data | treatment | form |
|---|---|---|
| Card number | Masked, except in the API response to its owner | ••••1111 — last four digits only |
| CLABE (18 digits) | Readable, except in webhooks and notifications | In full; in webhooks and notifications, •••• and the last four digits |
| Phone number | Masked in verification contexts | +52 55 ••••1234 |
The difference is not arbitrary. A CLABE is bank routing information: it identifies the destination account and is needed to reconcile a transfer. A card number is equivalent to the payment credential, and exposing it has different consequences.
Card masking keeps the last four digits because that is what lets a person recognise which of their cards it is, without the value being usable.
Where it applies
Masking covers the audit log, security events, the candidate accounts suggested by a validation error, webhooks and notifications. GET /v1/validations/{id} returns the full account to its owner in request_data and normalized_data. A card number appearing in a request path is also masked when logged, so it never remains in the clear in any history.
Receipts that arrive already masked
A receipt may arrive with the account already masked at source — common in receipts issued by banking apps. The validation flags this with is_masked.
That case changes what can be asserted about the result: with a partial account, the match is established over the available digits rather than the full number. The field lets the consumer know whether the verdict rested on complete data or on a truncated value.
BIN lookup
GET /v1/public/bin-lookup/{bin} accepts between 6 and 16 digits but uses only the first 6 to 8, and the response returns only the matched prefix, never the value received.
Even so, sending a full card number puts that value in the URL, where intermediaries outside this API may log it. The recommendation is to send only the prefix.