Processors

A processor is the connection between TagadaPay and the party that actually moves the money. Every store points at one or more processors, and every charge is executed by exactly one of them.

Two ways to get paid

TagadaPay (managed)

We are your payment provider. You hold no processor credentials — onboarding, underwriting, acquiring, settlement, payouts and disputes all run through TagadaPay. Configured as a single processor of type tagadapay-router.

Bring your own processor

You already have a merchant account. You give us the credentials and we drive it through a connector. You keep the acquiring relationship, the settlement and the risk.

With TagadaPay managed, the underlying acquiring is arranged for you and can differ by account, currency and region. You integrate against tagadapay-router and never against a specific acquirer — which methods your account can charge is answered at runtime by paymentSetup.

The operation contract

Every processor implements the same seven operations. Your integration calls the same API regardless of who is behind it.

Operation	What it does
`purchase`	Authorize and capture in one call. The default for most checkouts.
`authorize`	Reserve funds without taking them.
`capture`	Take previously authorized funds.
`void`	Cancel an authorization before capture.
`refund`	Return captured funds, in full or in part.
`verify`	Validate an instrument without charging it (zero-amount / account check).
`retrieve`	Re-read a transaction’s current state from the processor.

Not every processor exposes all seven. Where a cell is — below, the operation is not available through that connector — calling it returns an unsupported_feature error rather than failing silently. Design your flows around purchase and refund, which are the most widely supported.

Capability matrix

Looking for which payment methods each processor can charge rather than which operations? That is the support matrix.

Processor	`type`	Purchase	Authorize	Capture	Void	Refund	Verify	Retrieve
TagadaPay (managed)	`tagadapay-router`	✓	✓	✓	✓	✓	✓	✓
Airwallex	`airwallex`	✓	✓	✓	✓	✓	✓	✓
Authorize.Net	`authorizenet`	✓	✓	✓	✓	✓	✓	✓
CCAvenue	`ccavenue`	✓	✓	—	—	—	✓	—
Checkout.com	`checkout`	✓	✓	✓	✓	✓	✓	—
ConvesioPay	`convesio`	✓	✓	✓	✓	✓	✓	✓
Finix	`finix`	✓	✓	✓	✓	✓	✓	✓
KessPay	`kesspay`	✓	✓	✓	✓	✓	✓	✓
Mastercard MPGS	`mastercard`	✓	✓	✓	✓	✓	✓	—
Network N-Genius	`ngenius`	✓	✓	✓	✓	✓	✓	—
NMI	`nmi`	✓	✓	✓	✓	✓	✓	—
Ovri	`ovri`	✓	✓	✓	✓	✓	✓	✓
Paysafe	`paysafe`	✓	✓	✓	✓	✓	✓	—
Stripe	`stripe`	✓	✓	✓	✓	✓	✓	—
Tap Payments	`tap`	✓	✓	✓	✓	✓	✓	✓

Availability in the integration is not commercial availability. This table says the connector exists and what it can do. It does not mean the processor is offered, contracted or supported for your account. Confirm with your account manager before designing around one.

Worth knowing

CCAvenue cannot capture, void or refund

CCAvenue exposes no capture, void or refund API to us — it can purchase, authorize and verify, but everything after the charge has to be issued from CCAvenue’s own back office, and TagadaPay will not know about it unless you record it.

Retrieve is not universal

Re-reading a transaction’s live state from the processor is only available on some connectors. Where retrieve is —, rely on our stored transaction record and the webhooks instead.

Testing without a real acquirer

Use sandbox credentials on your processor, or the built-in simulator — see Sandbox testing.

Configuring a processor

Credentials are stored per processor and never leave the backend.

import { Tagada } from '@tagadapay/node-sdk';

const tagada = new Tagada({ apiKey: process.env.TAGADA_API_KEY });

await tagada.processors.create({
  processor: {
    name: 'Stripe — EU entity',
    type: 'stripe',
    enabled: true,
    baseCurrency: 'EUR',
    supportedCurrencies: ['EUR', 'USD'],
    options: {
      secretKey: 'sk_live_***',
      publicKey: 'pk_live_***',
    },
  },
});

Field names differ per processor — see Processor credentials.

Routing across several processors

A store can hold more than one processor and route between them — for load balancing, for per-currency routing, or to retry a declined card on a second acquirer. That is configured as a payment flow:

await tagada.paymentFlows.create({
  data: {
    name: 'EU cascade',
    strategy: 'cascade',
    pickProcessorStrategy: 'weighted',
    fallbackMode: true,
    maxFallbackRetries: 3,
    threeDsEnabled: true,
    stickyProcessorEnabled: true,
    processorConfigs: [
      { processorId: 'proc_primary', weight: 70, disabled: false, nonStickable: false },
      { processorId: 'proc_secondary', weight: 30, disabled: false, nonStickable: false },
    ],
    fallbackProcessorConfigs: [{ processorId: 'proc_backup', orderIndex: 0 }],
  },
});

See Multi-processor routing for cascade rules and retry semantics.

Support matrix

Which methods each processor can charge.

Alternative payment methods

Klarna, iDEAL, PayPal and the redirect lifecycle.

From the SDKs

Charging any of this from our packages.

Overview

Payments

Web Integration

Tracking & Attribution

Node SDK

Funnels

Funnel demos

Examples

Shopify

WooCommerce

SaaS Billing

Headless SDK

Plugin SDK

Plugin CLI

Studio MCP (AI Agents)

Config MCP (AI Agents)

Hosting & A/B Testing

Internal

Processors

Processors

Two ways to get paid

TagadaPay (managed)

Bring your own processor

The operation contract

Capability matrix

Worth knowing

Configuring a processor

Routing across several processors

Next

Support matrix

Alternative payment methods

From the SDKs

​Processors

​Two ways to get paid

TagadaPay (managed)

Bring your own processor

​The operation contract

​Capability matrix

​Worth knowing

​Configuring a processor

​Routing across several processors

​Next

Support matrix

Alternative payment methods

From the SDKs

Processors

Two ways to get paid

The operation contract

Capability matrix

Worth knowing

Configuring a processor

Routing across several processors

Next