Attach a payment instrument to a beneficiary. The credentials you submit (bank account numbers, wallet addresses, card PANs) are tokenized in Basis Theory on receipt — Anton’s core database stores only a token reference, a display-only masked value, and a content fingerprint used for cross-merchant deduplication.
The request body shape depends on the method — each method has a distinct
credential schema. See the Instruments methods endpoint
for the full per-country method catalog.
Requires an Idempotency-Key header.
API keys are opaque strings prefixed by environment:
ak_live_* — production keys, accepted only on api.antonpayments.com.ak_test_* — sandbox keys, accepted only on api.antonpayments.dev.Include your key in the Authorization header: Bearer ak_test_....
Unique key identifying this operation. Sending the same key twice returns the original response instead of creating a duplicate. Keys are retained for 24 hours.
255^ben_[a-zA-Z0-9]+$Create an instrument attached to a beneficiary.
The credentials object shape varies by method. A few common shapes:
iban: { "iban": "GB82WEST12345698765432", "bic": "WESTGB22" } (BIC optional)uk_bank: { "account_number": "12345678", "sort_code": "123456" }us_bank: { "routing_number": "026073150", "account_number": "...", "account_type": "checking" }crypto: { "wallet_address": "0x...", "network": "ethereum", "token_symbol": "USDC" }card: { "pan": "...", "expiry_month": 12, "expiry_year": 2028 } (routed through PCI vault)Call GET /v1/payment-methods?country=XX for the complete per-country catalog
with the exact credential schema required.
Credential format of a payment instrument — named by what data is stored, not by the rail that delivers the funds. One credential type can route to multiple rails (e.g. an IBAN can go via SEPA, SEPA Instant, TARGET2, SWIFT, or CHAPS — the rail is selected at payout time).
Query GET /v1/payment-methods for the full country-specific catalog
including per-method credential schemas.
iban, uk_bank, us_bank, ca_bank, au_bank, nz_bank, jp_bank, in_bank, za_bank, ng_bank, ph_bank, cl_bank, co_bank, swift, clabe, cbu, cci, pix, upi, interac, paynow, fps_hk, promptpay, card, crypto, mobile_money ISO 4217 three-letter currency code.
^[A-Z]{3}$"USD"
ISO 3166-1 alpha-2 country code.
^[A-Z]{2}$"US"
Merchant-visible label for this instrument (e.g. "Payroll - primary account").
255Method-specific credential fields. Tokenized on receipt.
Make this the default instrument for the beneficiary. The previous default (if any) is unflagged.
Instrument created.
A payment destination attached to a beneficiary. Credentials (account numbers, wallet addresses, card PANs) are tokenized in Basis Theory and never returned by the API. Only masked display fields and method metadata are exposed.
^ins_[a-zA-Z0-9]+$"ins_01HX8Z9K0M2N3P4Q5R6S7T8UA2"
^ben_[a-zA-Z0-9]+$^mer_[a-zA-Z0-9]+$Credential format of a payment instrument — named by what data is stored, not by the rail that delivers the funds. One credential type can route to multiple rails (e.g. an IBAN can go via SEPA, SEPA Instant, TARGET2, SWIFT, or CHAPS — the rail is selected at payout time).
Query GET /v1/payment-methods for the full country-specific catalog
including per-method credential schemas.
iban, uk_bank, us_bank, ca_bank, au_bank, nz_bank, jp_bank, in_bank, za_bank, ng_bank, ph_bank, cl_bank, co_bank, swift, clabe, cbu, cci, pix, upi, interac, paynow, fps_hk, promptpay, card, crypto, mobile_money active, disabled Whether this is the beneficiary's default instrument for payouts.
RFC 3339 / ISO 8601 timestamp in UTC.
"2026-04-15T14:30:00Z"
RFC 3339 / ISO 8601 timestamp in UTC.
"2026-04-15T14:30:00Z"
ISO 4217 three-letter currency code.
^[A-Z]{3}$"USD"
ISO 3166-1 alpha-2 country code.
^[A-Z]{2}$"US"
Merchant-visible label.
Last 4 characters of the primary credential (account number / PAN / wallet address), for display.
Bank name derived from routing details, for display.
Card network or chain, for display (e.g. visa, ethereum).
Fully masked credential for list views.
"****5432"