Introduction

Travel platforms need more than booking payments. Agents and corporate clients often need spend instruments — pay hotels, airlines, OTAs, and foreign suppliers online without sharing a company debit card or waiting on wire transfers.

Building card issuing yourself means scheme relationships, compliance, PCI scope, and years of infrastructure. Banking-as-a-Service changes that: you call a Cards API; the provider handles the rails.

This tutorial covers virtual card issuance with Anchor for travel & hospitality products — issue, fetch, and manage card status — with a travel-agent / corporate-client use case.

Verify all paths, resource types, and attributes against docs.getanchor.co before production. Card APIs are sensitive; never expose full PAN/CVV in logs or public tutorials beyond what sandbox docs allow.

Prerequisites

Anchor sandbox account and API key
Verified customer (individual or business) per your KYC rules
Node.js 18+ or any HTTP client

ANCHOR_SANDBOX_KEY=your_key_here
ANCHOR_BASE_URL=https://api.sandbox.getanchor.co

Travel architecture on Anchor cards

Traveler / agent / corporate client
        ↓
Customer + KYC on Anchor
        ↓
Issue virtual (often USD) debit card
        ↓
Spend: hotel, flight, foreign service online
        ↓
Controls: freeze, limits, status updates

Companion products (other weeks):

Product	Travel use
Virtual accounts	Collections per reservation
Bulk transfer	Settle hotels after checkout
Sub-accounts	Multi-property ring-fencing
Cards (this week)	Agent / corporate online spend

What Anchor Cards unlocks

From Anchor Cards: branded physical and virtual debit cards via API.

For travel startups specifically:

Persona	Card use
Travel agent	Book hotels/flights for clients
Corporate travel manager	Controlled employee trip spend
Traveler (B2C)	Prepaid trip wallet as card

Compliance, card scheme relationships, and issuing infrastructure stay with Anchor. You ship product UX.

Step 1 — Ensure customer is ready

Cards attach to customers. Create (or reuse) an individual/business customer and complete required KYC before issuance.

// Customer creation covered in earlier tutorials —
// confirm card prerequisites in current Cards docs.

If issuance fails with KYC-related errors, fix verification first — don't retry blindly.

Step 2 — Issue a virtual card

Playbook-shaped request (confirm fields in live docs):

cURL

curl --request POST \
  --url "$ANCHOR_BASE_URL/api/v1/cards" \
  --header 'Content-Type: application/json' \
  --header "x-anchor-key: $ANCHOR_SANDBOX_KEY" \
  --data '{
    "data": {
      "type": "Card",
      "attributes": {
        "cardType": "VIRTUAL"
      },
      "relationships": {
        "customer": {
          "data": {
            "type": "IndividualCustomer",
            "id": "CUSTOMER_ID_HERE"
          }
        }
      }
    }
  }'

TypeScript

const ANCHOR_KEY = process.env.ANCHOR_SANDBOX_KEY!;
const BASE_URL = process.env.ANCHOR_BASE_URL ?? "https://api.sandbox.getanchor.co";

async function issueVirtualCard(customerId: string, customerType = "IndividualCustomer") {
  const res = await fetch(`${BASE_URL}/api/v1/cards`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-anchor-key": ANCHOR_KEY,
    },
    body: JSON.stringify({
      data: {
        type: "Card",
        attributes: {
          cardType: "VIRTUAL", // confirm enum in docs
        },
        relationships: {
          customer: {
            data: { type: customerType, id: customerId },
          },
        },
      },
    }),
  });

  if (!res.ok) {
    throw new Error(`Issue card failed (${res.status}): ${await res.text()}`);
  }

  return res.json();
}

Save data.id as cardId. Treat sensitive fields as secrets.

Step 3 — Fetch card details

async function getCard(cardId: string) {
  const res = await fetch(`${BASE_URL}/api/v1/cards/${cardId}`, {
    headers: {
      accept: "application/json",
      "x-anchor-key": ANCHOR_KEY,
    },
  });

  if (!res.ok) {
    throw new Error(`Fetch card failed (${res.status})`);
  }

  return res.json();
}

curl --request GET \
  --url "$ANCHOR_BASE_URL/api/v1/cards/CARD_ID_HERE" \
  --header "x-anchor-key: $ANCHOR_SANDBOX_KEY"

In your travel product UI: show last4, expiry, status — never dump full PAN to support tickets.

Step 4 — Update card status

Travel ops need controls: trip ends, fraud suspicion, agent offboarding.

async function updateCardStatus(cardId: string, status: string) {
  // Confirm HTTP method + attribute names in docs (PATCH/PUT)
  const res = await fetch(`${BASE_URL}/api/v1/cards/${cardId}`, {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json",
      "x-anchor-key": ANCHOR_KEY,
    },
    body: JSON.stringify({
      data: {
        type: "Card",
        id: cardId,
        attributes: {
          status, // e.g. FROZEN / ACTIVE — confirm enum
        },
      },
    }),
  });

  if (!res.ok) {
    throw new Error(`Update card failed (${res.status}): ${await res.text()}`);
  }

  return res.json();
}

Map statuses to product language: "Pause card", "End trip spend", "Revoke agent card".

Travel product flow (put it together)

async function provisionTravelAgentCard(agent: {
  customerId: string;
}) {
  const issued = await issueVirtualCard(agent.customerId);
  const cardId = issued.data.id;
  const details = await getCard(cardId);

  // Store cardId against agent profile in your DB
  // Display last4 + status in agent dashboard
  // Never persist full PAN unless PCI-compliant vaulting

  return { cardId, details };
}

BaaS vs building cards yourself (short)

Approach	Reality for a travel startup
Build / direct bank+scheme	Years, huge compliance, capital
Fintech API / BaaS (Anchor)	Issue cards via API; focus on bookings UX

If your roadmap says "give agents a virtual card for bookings," BaaS is usually the only path that fits startup timelines.

Resources

@anchor_build on X
MCP (live docs in AI tools): https://docs.getanchor.co/mcp