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.

​
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

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