Create a customer (individual or business) and associated deposit account in Unit; the deposit account provides the funding source for card transactions and must be in an active state before card issuance is possible
Issue a debit card via the Unit card issuance API, specifying the deposit account ID as the linked account, the cardholder name, shipping address for a physical card or configuration for a virtual card, and any initial spending limits; Unit returns a card object with a card ID and masked PAN
Configure spending controls on the card object: set daily spend limits, monthly limits, individual transaction limits, and merchant category code (MCC) allow lists or block lists via the card limits endpoint; spending controls are enforced in real time at card authorization
Implement a real-time authorization webhook handler (using Unit's card transaction webhooks or a card authorization control integration) to receive pre-authorization events if Unit supports authorization controls for your program; respond with approve or decline decisions within the required latency window
Subscribe to card transaction webhooks to receive authorization, clearing, and return events; map each transaction to the associated deposit account and post corresponding ledger entries — debit the customer deposit balance on authorization hold and settle on clearing, reversing the hold and posting the cleared amount
For 3-D Secure (3DS) enabled cards, implement the cardholder authentication challenge flow by handling the 3DS authentication webhook if applicable to your card program configuration
Known gotchas
Card authorization holds are placed immediately at authorization time but may differ from the final cleared amount (e.g., tips at restaurants, fuel pre-authorization); ledger logic that settles the held amount on clearing without checking the cleared amount will produce balance errors when the cleared amount differs from the original authorization
Unit's card issuance goes through a card network program managed by the sponsor bank and the card network (Visa or Mastercard); changes to spending controls take effect at the next authorization check but may not retroactively cancel pending authorization holds already placed by merchants
Virtual card numbers issued for single-use or merchant-locked purposes have specific tokenization requirements; reusing a single-use virtual card number or attempting to charge a merchant-locked card at a different merchant will result in a decline at the network level with a response code that differs from a standard insufficient-funds decline
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp