Cards

Prompt for AI· paste into Claude, ChatGPT, Cursor or any coding agent

Read the Rubin Cards docs starting at https://docs.rubin.trade/cards/overview (with the Keys & Authentication, Integration Flow and API Reference pages) and add virtual cards to my app. Work against testnet https://processing.testnet.rubin.trade: generate a non-custodial Rubin key per user as described on the Keys page, fund the address from the testnet faucet and sign requests with the cosmos scheme. Read tariffs from GET /v4/providers, show the price from GET /v4/{provider}/quote, pay with MsgOrder signed by the user key (retry a payment only with the same ref), report the ref to POST /v4/{provider}/orders/paid and poll the order until it is completed. Then add card details, PIN, top-up, payment history and 3-D Secure codes. Never log card numbers, PINs or one-time codes.

Open in Claude ↗Open in ChatGPT ↗

Rubin Cards lets a user issue a virtual Visa or Mastercard card, pay for it and top it up with USDC from their Rubin address, spend it, and see the payment history. The card section of rubin.trade is built on the API described here, so a partner can offer the same cards in their own product.

Start with a key

There are no API keys and no partner accounts. A customer is a Rubin address, and every request and every payment is signed by the key of that address. The key stays with you or with the user: Rubin never sees it and cannot move the USDC on the address.

Generate a key first: Keys & Authentication.

How it works

Customer = Rubin address. The address that signs a request owns the cards and sees only its own cards, orders and history.
Funding. The customer's USDC sits on the main account of that address. It gets there through Onramp, a bridge deposit or a transfer inside Rubin.
Tariff and price. GET /v4/providers returns the tariffs and limits. GET /v4/{provider}/quote returns the exact USDC price of an operation.
Payment. The customer's key signs an on-chain MsgOrder, which moves the USDC from the address to the card provider's reserve. The service has no way to take money from the address by itself.
Execution. The service finds the payment on chain and asks the card provider to issue or top up the card. If that fails, the whole payment returns to the same address automatically, unless the order goes to manual_review, where it waits for support.
Using the card. Card details, PIN, payment history and one-time codes are read through the API. The cardholder spends the card like any other online card.
Getting money back. On tariffs that allow it, the card balance can be withdrawn: the USDC is credited back to the address.

                     1. MsgOrder (USDC, signed by the customer's key)
Customer key ───────────────────────────────────────────────► Rubin chain
     │                                                             │
     │ 2. POST /orders/paid {ref}                                  │ payment found by ref
     ▼                                                             ▼
Processing API ◄───────────────────────────────────────────────────┘
     │
     │ 3. issue or top up at the card provider
     ▼
   Card ── details, PIN, codes, history ──► your app
     │
     └── provider refused ──► MsgRefund: full payment back to the address

Environments

Network	Cards API base URL
Mainnet	`https://processing.mainnet.rubin.trade`
Testnet	`https://processing.testnet.rubin.trade`

All paths in this section are relative to the base URL. On testnet the card provider is a simulator: no real cards are issued, and purchases can be simulated.

The `{provider}` path segment

Customer endpoints live under /v4/{provider}/…, where {provider} is the id from GET /v4/providers. Read it from that response and do not hard-code it: the value differs between networks and more providers can appear. A card always stays with the provider that issued it.

What the API covers

Task	Endpoint
Tariffs and limits	`GET /v4/providers`
Price of an operation	`GET /v4/{provider}/quote`
Issue a new card	`MsgOrder` + `POST /v4/{provider}/orders/paid`
Top up a card	`MsgOrder` + `POST /v4/{provider}/orders/paid`
Withdraw from a card	`POST /v4/{provider}/orders`
Order status	`GET /v4/{provider}/orders/{orderId}`
List cards, read a card	`GET /v4/{provider}/cards`, `/cards/{cardId}`
Card number, CVC, PIN	`POST /v4/{provider}/cards/{cardId}/reveal`
Set or change the PIN	`POST /v4/{provider}/cards/{cardId}/password`
Payment history	`GET /v4/{provider}/operations`, `/operations/summary`, `/operations/export`
3-D Secure and wallet codes	`GET /v4/{provider}/verification-codes`
Change signals	`GET /v4/{provider}/events/channel` + WebSocket
Rename or close a card	`POST /v4/{provider}/cards/{cardId}/rename`, `/deactivate`

Every endpoint is described in the API reference.

Not available: freezing a card temporarily (closing is permanent) and webhooks (use the change signals and polling). A created order cannot be cancelled by the customer.

What the partner does and does not do

Does: keeps a Rubin key per end user (or uses the user's own wallet), signs requests and payments, shows one-time codes to the cardholder, and polls orders until they finish.
Does not: hold user funds. USDC stays on the user's address until the user's key pays an order. Refunds and withdrawals return to the same address.
Does not: receive payment notifications from Rubin by itself. There are no webhooks: your app reads the state over the API.