Skip to main content

​
Choose how you accept payments

Four ways to accept a payment. They are not interchangeable. Combining two paths on the same customer-initiated payment (CIT — your customer is present) is the most common integration mistake. Working Headless example: headless-vanilla.

​
The fifth path: raw card data (on request only)

Almost every integration should tokenize in the browser with @tagadapay/core-js, which keeps the card number out of your servers and your PCI scope at SAQ-A. One exception: merchants who are already PCI-DSS compliant and hold card numbers in their own environment — typically because they use several PSPs and collect cards themselves. Those can send the card straight from their server with paymentInstruments.createFromCard().
TagadaPay has to switch this on for your account. It is off by default, for everyone.Until we do, the call fails with Please contact support to ask for raw card data enablement. Ask your account manager or contact support, and be ready to evidence your PCI-DSS compliance. Do not plan an integration around this path before it has been granted.
The card goes from your server directly to TagadaPay’s PCI vault; only the resulting vault token reaches the TagadaPay API. Full walkthrough in Server-to-server payments.

​
Same name, different call

​
What not to do

Headless dynamically imports @tagadapay/core-js for tokenizeCard(). Install both. That is the intended pairing, not two competing checkouts.
First payment (customer present) with Headless processPayment() or core-js + /payments/process. Later charges use Node payments.process() against the saved instrument. Same card, two different moments.
A checkout session is not a payment. If you createSession() and then call /payments/process without paying that session, the cart is left unpaid, 3DS returns to the wrong page, and the hosted checkout link often points to a placeholder. Pick one path for the first payment.

​
Headless returnUrl vs checkoutUrl

On a self-hosted Headless checkout:
  • returnUrl is the page that hosts usePayment / maybeResumeFromUrl. After 3DS the bank sends the shopper back there.
  • checkoutUrl is generated by TagadaPay. Headless cannot set it. Do not redirect the shopper to session.checkoutUrl when you are rendering checkout yourself.
  • To hop from a cart page to your own checkout path, use tagada.checkout.createSessionUrl() — it builds a URL on your origin with checkoutToken + sessionToken.
checkoutUrl is for TagadaPay-hosted checkouts only.

​
Next steps

What can you accept?

Every card, wallet and APM, per processor — the support matrix

Accept a payment with your own cart

Tokenize in the browser, charge with payments.process

Headless SDK

Custom UI, TagadaPay manages the cart

Plugin SDK

Pages hosted on TagadaPay

Node SDK

Server charges, including later rebills