---
title: "KTAP Cards API"
description: "Issue virtual Visa cards to your own customers and fund them from a prepaid USD balance."
kind: explanation
url: /docs
canonical_url: "https://virtual.ktap.io/docs"
---

> Part of the KTAP Cards API documentation.
> Index of every page: https://virtual.ktap.io/llms.txt
> Machine-readable schema: https://virtual.ktap.io/api/partner/v1/openapi.json

# KTAP Cards API

Issue virtual Visa cards to your own customers and fund them from a prepaid USD balance.

Issue virtual Visa cards to your own customers, fund them from a prepaid USD balance, and reconcile everything against one ledger. Your customers never contact us and never see our name.

## How it works

1. You hold a prepaid USD balance with us. You fund it by sending USDC or USDT on Polygon, BNB Chain or Base, directly from a wallet you have registered with us, to the funding address [GET /funding/addresses](https://virtual.ktap.io/docs/api/account.md#listFundingAddresses) returns, then submitting the transaction hash to [POST /funding](https://virtual.ktap.io/docs/api/account.md#submitFunding) to confirm the deposit. One load fee is charged when it is credited.
2. You order a card for a customer with a name, a mobile number and an email address, and get back a card id. The name goes in as the user wrote it: accents convert automatically and punctuation like O’Brien is fine.
3. You move money from your balance onto the card at 1:1, with no further load fee, and can pull it back off a card the same way without closing it.
4. You show the card number to your customer through a short-lived URL we mint for your page or their device. The number itself never reaches your servers.
5. Your customer spends. We tell you what happened over webhooks, and each purchase's fee is on its `card.authorized` event.

The card is a virtual Visa: no plastic, usable anywhere Visa is accepted online, and addable to Google Pay but not to Apple Wallet. It is denominated in USD. Every purchase carries a fee, charged with the purchase amount at authorization, and a purchase in another currency is also converted. The cardholder name is printed in uppercase, at most 26 characters: José becomes Jose automatically, Müller keeps its umlaut, and the only characters refused are the few with no plain ASCII stand-in, such as ß and non-Latin scripts. 3-D Secure codes go by SMS to the number you supplied when you ordered the card, and you can [change that number later](https://virtual.ktap.io/docs/api/cards.md#updateCardPhone) if the cardholder switches. Programs that would rather deliver the code in their own app can [switch a card to webhook delivery](https://virtual.ktap.io/docs/api/cards.md#setCard3dsMethod) once we enable it for them.

## Base URL and authentication

One base URL, one key, sent as a header on every request from your own server. Keys are issued by your account manager; there is no self-serve signup.

```bash
curl https://virtual.ktap.io/api/partner/v1/me \
  -H "X-API-Key: $KTAP_API_KEY"
```

> **Every key is live and there is no sandbox**
>
> There is no test mode and no simulated card. Build against a real card you issue for the purpose, fund it with a small amount, and close it when you are done. A test card still carries one month of card fee.

## Where to go next

- [Quickstart](https://virtual.ktap.io/docs/quickstart.md): Issue a card, fund it, read it back. Six calls.
- [Essentials](https://virtual.ktap.io/docs/essentials.md): Auth, errors, idempotency, paging and limits. Read once.
- [API reference](https://virtual.ktap.io/docs/api/account.md): Every endpoint, with parameters, responses and samples.
- [Webhooks](https://virtual.ktap.io/docs/webhooks.md): Register a callback, verify the signature, and backfill anything you missed.

Questions, or a problem in production: [dev@ktap.io](mailto:dev@ktap.io). Include your key prefix, the card id, the idempotency key if there was one, and the time in UTC.
