Skip to main content

Payment Setup

The payment module is the core of the Headless SDK. It lets you discover which payment methods are configured for a store, tokenize cards, and process payments with automatic 3DS, redirect, and polling handling.

Discover Available Payment Methods

Every store has a payment setup config — a map of payment methods (card, Apple Pay, Google Pay, Klarna, etc.) with their enabled/disabled state, processor IDs, and flow IDs.
Where the config comes from, in order: an explicit paymentSetupConfig you pass in, the config injected on Tagada-hosted pages, and otherwise the payment methods enabled on the store for that checkout session (resolved from the API). Keys are method or method:provider — so on a self-hosted page an Apple Pay integration shows up as "apple_pay", the card form as "card". An empty object means no payment method is enabled for the session’s store/currency.

Just the enabled method keys

Express methods with browser availability

The SDK automatically checks ApplePaySession.canMakePayments() in the browser to determine Apple Pay availability.

Card Payment Flow

processPayment() is the high-level orchestrator that handles the entire payment lifecycle automatically:
  1. Submits payment to the processor
  2. If 3DS / bank auth is required → redirects the user and resumes on return
  3. If the payment is async → polls until a terminal status
  4. Returns a typed ProcessPaymentResult
tokenizeCard() requires @tagadapay/core-js as an optional peer dependency. Install it: npm install @tagadapay/core-js.

Return type: ProcessPaymentResult

The return value is a discriminated union — check result.status for exhaustive handling:

3DS Return URL

After a 3DS redirect, the bank sends the user back to your page with query parameters. The SDK auto-detects these and resumes the payment:
  • React (usePayment): Handled automatically on mount — detects ?paymentAction=... params, polls for result, fires callbacks.
  • Vanilla JS: Call tagada.payment.maybeResumeFromUrl() on page load. That is the one-liner. resumeAfterRedirect(paymentId) is the lower-level equivalent if you already parsed the query yourself.
returnUrl passed to processPayment() (defaults to window.location.href) must be the page that runs this resume hook. After 3DS the bank sends the shopper back there.

Express Checkout

Apple Pay

Merchant-scoped Apple Pay domains. When the checkout domain runs merchant-scoped Apple Pay — either the merchant’s own Apple certificates (BYOK) or Tagada’s platform-integrator registration — the backend attaches a domain-keyed applePayByok map to the apple_pay method’s metadata. The SDK resolves the current hostname against that map automatically and sends the matching merchant_registration_id to Basis Theory during tokenization, so no code change is needed. Pass merchantRegistrationId explicitly on processApplePay only to override the automatic resolution, or call tagada.payment.resolveApplePayRegistration() yourself when minting the Apple Pay merchant session (its merchantRegistrationId and displayName must go into the Basis Theory POST /apple-pay/session call for these domains).

Google Pay

Redirect APMs (Klarna, iDEAL, etc.)

For the APM lifecycle rules (redirect → webhook, vouchers, recurring limits) see Alternative payment methods.

React Hook

Full Hook API


Advanced API

For advanced use cases, you can create instruments and process payments separately:

Test your integration

In sandbox, any 16-digit card works. Use this one:
  1. Call processPayment() and confirm result.status === 'succeeded'.
  2. Confirm returnUrl is the page that runs maybeResumeFromUrl() (vanilla) or usePayment (React). After a 3DS challenge the bank sends the shopper back there.
Full sandbox setup: Sandbox testing.
Need even more control? For instrument-level management, later charges (MIT — merchant-initiated, customer not present), auth+capture, or mobile apps, see Accept a payment with your own cart.