Skip to main content

Customer Portal

tagada.portal lets you build the customer account area of your store in your own code: the customer logs in with a code sent by email, then sees their orders and subscriptions and manages them — skip, pause, change frequency, swap product, cancel with your retention offers, update addresses and cards, order again, spend credits. It is the same API as the portal TagadaPay hosts on /account of your checkout domain. Both read the portal you configure in the CRM under Customer portal: which actions are allowed, per store and per product, the cancellation reasons and the retention offer of each, the membership program. A rule you change there applies to your headless portal too. Requirements
  • @tagadapay/headless-sdk 1.17.0 or later.
  • A client created without apiKey. The SDK sends the API key in place of the customer’s session when one is set, and the portal then refuses every call.

Log in

After verifyCode, the client sends the session with every call. The session lives in the client only: keep token yourself (for example in sessionStorage) and give it back after a page reload with tagada.setSessionToken(token). requestCode answers 404 when the store has no customer with that email.

Read the portal


Manage a subscription

The everyday actions live on tagada.customer and return nothing; the newer ones live on tagada.portal and return { subscriptionId, status }. Both need the logged-in session. sendNow and retryPayment answer status: 'past_due' while the charge settles; read getMe() again to see the outcome.

Permissions

Every action can be turned off in the CRM, for the store or for one product; they are all on by default. A refused action throws TagadaAuthError with a message that says why (“This store does not offer this change for this product”). A missing or expired login throws the same class, so read error.message before sending the customer back to the login screen. A subscription with a minimum number of paid orders cannot be cancelled before it reaches it:

Cancel with retention offers

getConfig().retention holds the cancellation reasons you configured, and the retention offer mapped to each (a discount, a skip, a pause, another frequency, a product swap, a yearly plan). The flow is yours to draw; the SDK applies the outcome:
  • target is { type: 'subscription', subscriptionId } or { type: 'membership' }.
  • acceptCancelOffer also takes what the customer chose inside the offer: optionId, productId, variantId, or days for a pause.
  • Both return { subscription, membership } as they stand after the change.
portal.switchOption({ target, optionId }) moves a subscription to another purchase option, or the membership to 'monthly' / 'yearly', charged now. It returns the orderId of that charge and status: 'paid' or 'requires_action' (see 3D Secure); with requires_action, the subscription is unchanged until the customer completes it.

Account


Buy from the portal

These charge the customer’s default card and ship to their default address. They return the orderId and a status of 'paid' or 'requires_action'.

3D Secure

When the card asks for authentication, a charging call returns status: 'requires_action' and a redirectUrl. Send the customer there to complete it.

Errors