Debit Cards

Cards

Issue, manage, and monitor Visa debit cards for customers under your GMA partner account.

Cards are physical Visa debit cards linked to a managed customer. As a GMA partner you can order a card for an eligible customer, view card details, control spend and ATM access, review fees and limits, and inspect transaction history.

You do not create customers through the Cards API. Customers must already exist and be associated with your partner account before a card can be ordered or managed. Sensitive card data such as full PAN, CVV, and PIN is never returned.

All endpoints require a session-token. The broker profile must have financial transactions enabled.

---

Key concepts

• Debit cards only — This API covers Visa debit cards. Credit cards are not supported.
• Card ownership — Every card belongs to a managed customer under your GMA partner account. You can only access cards for customers associated with your partner account.
• Card reference — Use the card identifier returned by the list endpoint as {cardId} on fees, limits, transactions, suspend, and ATM endpoints.
• Ordering — Use POST /cards/order to request a physical debit card for a managed customer. The call completes in the same request and returns the order result. Delivery address and related fields are required at order time.
• Spend controls — Suspend or resume card spend with POST /cards/{cardId}/suspend. Enable or disable ATM usage with POST /cards/{cardId}/atm.
• Fees — GET /cards/{cardId}/fees returns configured fee values as currency strings with a leading $ (for example "$25.00").
• Limits — GET /cards/{cardId}/limits returns purchase and ATM limits, including daily, monthly, per-transaction, and per-ATM-transaction values where configured.
• Transactions — GET /cards/{cardId}/transactions returns card activity. Filter by date range, amount, merchant, country, MCC, and transaction type. Country accepts a name or ISO code. Numeric MCC values match the merchant category code exactly. Results are limited to 200 rows (newest first); there is no PageNumber / PageSize pagination.
• Field casing — Path params use camelCase (userId, cardId). Body, query, and response fields use PascalCase (for example UserId, CardId, AtmEnabled, Suspended).

Sample values: userId / UserId = -8202289338547523753, cardId = 55d0c52f-79ee-4d38-acf4-a16c07957898.

---

Changelog

• Create Card Order — POST /cards/order is synchronous (creates the card order and returns the final result in the same request).
• Transactions filters — Mcc numeric = exact MCC code; text = description match. Country accepts name / alpha-2 / alpha-3 / ISO numeric and matches transaction + acquiring institution country.
• Limits — added PerTransactionLimit and PerAtmTransactionLimit (same resolve order as other limits).
• Fees — fee amounts are $xx.xx currency strings (not bare numbers).

---

What is available

Capability	Endpoint
Create / order physical debit card	POST /cards/order
List cards for a customer	GET /cards/{userId}
Suspend / resume spend	POST /cards/{cardId}/suspend
Enable / disable ATM	POST /cards/{cardId}/atm
Get configured fees	GET /cards/{cardId}/fees
Get limits	GET /cards/{cardId}/limits
List card transactions	GET /cards/{cardId}/transactions

---

Common workflow

1. POST /cards/order with PascalCase address + MothersMaidenName (synchronous).
2. GET /cards/{userId} — list cards (CardId = card reference ID).
3. Once CardStatus is Active, use suspend/resume and ATM toggle as needed.
4. Use fees, limits, and transactions endpoints by cardId after the card exists.

Empty list behavior: If the customer exists and the broker has access but no cards exist, GET /cards/{userId} returns HTTP 200 with ResponseData as the string "Card not available" (not 404).