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-sdk1.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
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 ontagada.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 throwsTagadaAuthError 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:
targetis{ type: 'subscription', subscriptionId }or{ type: 'membership' }.acceptCancelOfferalso takes what the customer chose inside the offer:optionId,productId,variantId, ordaysfor 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 returnsstatus: 'requires_action' and a redirectUrl. Send the customer there to complete it.
