TagadaPay for Partners

Who this is for — Companies who run their own merchant-facing product (PSPs, marketplaces, embedded-payments platforms, recurring-billing tools, virtual terminals) and want to use TagadaPay as their payment infrastructure.Your merchants never see TagadaPay. They see your brand, your dashboard, your support. TagadaPay sits behind your service, processes the cards, returns the money to your merchants’ bank accounts.Building a single store for yourself instead? You’re in the wrong tab — head to Developer Tools for merchant SDKs (Headless, Plugin, Node, Studio MCP…).

What you can do as a partner

Capability	API surface
Provision a sub-merchant programmatically (KYB, store, settlement currency)	`tagada.partners.accounts.create()`
Mint an API key restricted to one specific sub-merchant	`tagada.partners.apiKeys.create()`
Discover what payment methods are available for that merchant	`tagada.paymentSetup.get(storeId)`
Tokenize cards / Apple Pay / Google Pay client-side (PCI-safe)	`@tagadapay/core-js`
Charge cards server-to-server	`tagada.payments.process()`
Initiate redirect APMs (Klarna, iDEAL, Bancontact, …)	`tagada.payments.process({ paymentMethod: 'klarna', ... })`
Run 3DS challenges when issuers require them	`tagada.threeds.createSession()`
Submit KYB documents and update requirements	`tagada.partners.documents.record()`

You only need two SDKs

@tagadapay/core-js

Runs in the browser. PCI-safe primitives that produce a single-use tagadaToken.

Card tokenization (Tokenizer.tokenizeCard)
Apple Pay (startApplePaySession)
Google Pay (startGooglePaySession)
Stripe Express Checkout (startStripeExpressCheckout)
3DS challenge handling
Wallet availability detection

@tagadapay/node-sdk

Runs on your server. Provisioning + charging, with the sub-key minted for each merchant.

partners.accounts.* — provision sub-merchants
partners.apiKeys.* — mint per-merchant sub-keys
paymentInstruments.* — turn tagadaToken into a charge-ready instrument
payments.* — charge, refund, capture, MIT
paymentSetup.* — discover what each merchant has enabled
threeds.* — create + verify 3DS sessions

That’s it. No checkout sessions to manage, no funnels to deploy, no React framework to opt into. You bring your own UI, your own server, your own merchant-facing product. We handle tokens, processors, and money.

Mental model in 30 seconds

You (the partner)              TagadaPay
─────────────                  ──────────

1. Sign up as a partner   ───► partner_id (par_xxx)
   API key                ───► tp_sk_partner_xxx  (full partner power)

2. Provision a merchant   ───► tpa_xxx + acc_xxx + store_xxx (auto-created)
                                each merchant gets their own private namespace

3. Mint a sub-key         ───► tp_sk_xxx (restricted to that one tpa_xxx)
                                this is the key your charging code uses

4. Tokenize browser-side  ───► tagadaToken (PCI-safe, single-use)

5. Charge server-to-server◄─── { payment_id, status, ... }
   with sub-key + storeId

The two-key model (partner key for provisioning, sub-key for charging) is the security boundary — if a sub-key leaks, only one merchant is exposed, never your whole partner account.

Where to start

Quick Start

The end-to-end S2S flow in 4 steps: provision → mint key → tokenize → charge. ~10 minutes to a successful payment.

Sub-merchant provisioning

The tagada.partners.accounts.* API: how TPAs, stores, and the orphan accounts row work together.

API keys & authentication

Partner key vs sub-key, scopes, rotation, secrets handling.

Server-to-server payments

Card flow, payment instrument lifecycle, refunds, captures, MIT.

Alternative payment methods

Apple Pay, Google Pay, Klarna, iDEAL — including the native vs through-processor distinction that determines which browser SDK to load.

Payment setup config

The method × provider shape of the runtime config — how to discover what payment methods a merchant has enabled.

Full end-to-end example

A complete partner integration: signup → charge → refund, with all the snippets in one place.

What this section is NOT

If you’re building…	Use instead
A web checkout for your own store	Headless SDK or Plugin SDK
A custom checkout page hosted on TagadaPay	Plugin SDK
A simple “Buy Now” button on an external site	Web Integration
Server automation for a single merchant’s store	Node SDK quick start

The “Partners” section assumes you’re acting on behalf of many merchants and need the multi-tenant primitives (TPAs, sub-keys, per-merchant store provisioning).

​TagadaPay for Partners

​What you can do as a partner

​You only need two SDKs