Documentation

Ship tap-to-pay in 12 days. These docs tell you how.

Guides, quickstarts, integration patterns, and the full API reference. Start with the 15-minute quickstart; the rest is here when you need it.

15-minute quickstart

This quickstart takes you from zero to a live sandbox tap in fifteen minutes. You'll create a Tapped account, install an SDK, register a sub-merchant, and charge a test card. Everything in sandbox is free and idempotent.

Install the SDK

Tapped SDKs are available on the native package managers for each platform. All SDKs use the same object model and call the same underlying API, pick whichever fits your stack.

Node & TypeScript

# Install via npm, pnpm, or yarn
npm install @tapped/node # or pnpm add, yarn add

# Minimal usage
import { Tapped } from "@tapped/node";

const tapped = new Tapped({ apiKey: process.env.TAPPED_API_KEY });
const charge = await tapped.charges.create({
  amount: 4850,          // minor units (cents)
  currency: "SGD",
  submerchant: "sm_9T3...",
  capture_mode: "tap"   // "tap" | "pre-auth" | "manual"
});

Your first live tap

In sandbox, every charge returns a mock EMV cryptogram and a fully-formed ledger entry. Charge a test card with 4242 4242 4242 4242 (Visa sandbox PAN) at any amount; the SDK returns a transaction record within ~400ms.

const tap = await tapped.taps.capture({
  amount: 4850, currency: "SGD",
  submerchant: "sm_9T3...",
  device: "dev_ios_a81..."    // provisioned phone
});

// tap.status === "approved"
// tap.cryptogram === "9F2608..."
// tap.latency_ms === 612

The transaction model

Every interaction with Tapped resolves to a transaction, one immutable record with a scheme-traceable chain from tap to payout. Transactions own their own disputes, refunds, and settlement references.

  • tap, the NFC contact moment, with cryptogram, BIN, and risk decision
  • authorisation, what the scheme approved or declined, with reason code
  • capture, money moved from issuer; locks in the FX if cross-currency
  • settlement, the entry in the merchant's Tap Ledger; pays out on a schedule

Sub-merchants

A sub-merchant is one of your platform's customers, a restaurant, a salon, a clinic. Tapped Onboard collects the KYB data, runs sanction and risk screens, registers the merchant with the appropriate acquirer, and returns a handle you use on every charge.

const sm = await tapped.submerchants.create({
  display_name: "Kanpai Makati",
  country: "PH",
  mcc: "5812",              // eating places
  business: {
    legal_name: "Kanpai Foods Inc.",
    tax_id: "009-283-112-000",
    incorporation_country: "PH"
  },
  owners: [{ name: "R. Del Mundo", ownership_pct: 52 }]
});
// sm.status === "pending_review"   (usually ~35 min)

Payouts & the ledger

Tap Ledger is a double-entry ledger that owns every cent from authorisation through payout. Ledger entries are queryable, reconcilable, and carry scheme references your finance team can match against scheme reports.

By default, sub-merchants settle T+1 to their own bank account. Platform fees accrue to a platform operating account in the same currency as the transaction. You can read more about payout schedules and currency handling in Tap Ledger.

Webhooks

Tapped emits webhooks for every state transition that matters to a platform, tap approved, dispute opened, payout settled, sub-merchant KYB completed. Webhooks are signed with HMAC-SHA256 and retried with exponential backoff for up to 72 hours.

Full reference: Webhooks →

Pattern: tap at the counter

Common for F&B and retail. The POS app holds an active tab; at close, the server presents the device to the guest; tap triggers taps.capture() directly (no pre-auth). Tips are appended to the authorisation via a single-call capture_mode: "tap_with_tip" pattern that pre-computes the tip menu for the locale.

Pattern: tap at the door

Common for field services and home repair. Pre-authorise at arrival (capture_mode: "pre-auth"); capture on job close. If the job scope expands, call authorisations.increase() in place; no re-tap required up to the pre-approved ceiling.

Pattern: the hotel folio

One authorisation at check-in holds the incidentals cap. Nightly room charges post against the authorisation without capturing. At check-out, the consolidated folio captures in a single call; unused portion of the incidentals auth releases. The entire stay sits under one authorisation_chain_id, a single rail for disputes.