Skip to main content
Issue a USD virtual card. Pass the cardholder’s KYC inline (the cardholder is created or reused automatically), or use the Cardholders flow to issue to an existing cardholder. initialBalance is debited from your USD card wallet (fund-first). Every card is a wallet-enabled USD card (addable to Apple/Google Wallet), so capability is optional — omit it, or send APPLE_PAY/GOOGLE_PAY explicitly.
Card endpoints use the same base URL and API key as the rest of the API, and are signature-gated: send X-Numero-Signature and X-Numero-Signature-Version: v2 as well. See Request signing.

Endpoint

Signature required: Yes

Headers

Request body

These KYC fields are required by the inline issuance route because it creates a new cardholder when necessary. To issue to an existing cardholder without resubmitting their stored KYC, use POST /business/cardholders/{customerId}/cards.

Funding and identity requirements

Set initialBalance to the total activation amount. The current minimum is USD 10.00, including USD 5 mandatory initial funding available to spend. The same amount must be available in the merchant’s USD CARD wallet. It is not enough to have funds in another USD wallet: check it with GET /business/balance?currency=USD&purpose=CARD. For a new cardholder, supply accurate contact details, date of birth, residential address, ID type/number and the required document image. Numero converts the image into the issuer’s required representation; developers send image URLs, not provider base64 payloads. The dashboard collects uploads and can reuse eligible activation documents; API clients supply the direct image URL. Do not substitute a portrait for an identity document or change identity types to bypass verification.

Errors and safe retries

Missing identity evidence and malformed document URLs return HTTP 400 with error.code: "validation_error" and the affected field in error.param, before funding is reserved. For example:
The same validation applies to test keys. Use synthetic identity details and a public HTTPS-shaped fixture URL such as https://documents.example/front.jpg in test mode; test-mode document handling does not download real identity evidence. Existing cardholders reuse their stored evidence where available. Invalid proof-of-funds answers identify proofOfFunds in error.param. Correct the named field rather than increasing the activation amount. If initialBalance is below the product’s customer-facing activation minimum, the response uses error.code: "activation_required" and error.param: "initialBalance". This is request validation, not a wallet-balance lookup; correct the requested total, then check the USD CARD wallet separately. An approved card product or an ACTIVE provider customer is not sufficient proof of complete card KYC. Missing identity evidence can block issuance. Retain Numero’s request ID and any existing cardholder reference; correct the evidence on the existing profile instead of creating duplicate customers. Do not disable KYC checks. Test keys use the same product code and field validation, but do not require a production card-product activation. An enabled product returned by GET /business/card/products is immediately issuable in test mode. A provider timeout or server error is not proof that nothing was created or debited. Check the card list, request outcome, USD CARD wallet statement and webhooks before retrying. A confirmed pre-issuance rejection with no card or wallet movement must not be presented as successful issuance. Issuance, funding and notification delivery are separate outcomes to reconcile.

Request example

Proof of funds and address

Both inline issuance and cardholder creation also accept: The proof-of-funds object uses camelCase Numero fields: employmentStatus, occupation, primaryPurpose, sourceOfFunds, expectedMonthlyPay. If provided, all five must contain valid documented options. See the machine-readable CardProofOfFunds schema for the complete accepted values. This is a questionnaire, not an extra document-upload URL. Provider KYC readiness is required before issuance; a locally created cardholder is not proof of approval.

Response

Returns the card (masked only). HTTP 200 alone does not confirm issuance: status: Pending with operationReference and operationStatus means processing or reconciliation is outstanding. Keep the reference and read the card again; do not submit another issuance while the first is unresolved. Use the returned card balance to determine the amount available to spend.