The customer portal

The customer portal turns your help site into an account page: signed-in customers see their payments, subscriptions and requests, and can ask for refunds and cancellations.

Every refund and cancellation the portal starts is decided by your published policy, exactly as in the chat. Nothing is approved by a person, and nothing the policy does not allow happens automatically: it goes to your team.

Turn it on

The portal is off by default. Without it, your help site shows customers only the requests they sent through your own form.

Open Settings → Help Site and Portal → Customer Portal. You need a role that manages the widget (owner, admin or developer).
Choose Turn the Customer Portal On. The confirmation says what changes; confirm with a code from your authenticator app.
Copy the Portal address from the card and link to it from your site and your emails.

The change takes effect at once and is recorded in the Audit Log as "Customer portal changed". Turning the portal off needs no code.

The card's How customers sign in line shows which methods are in force. It follows the Identity step of your published policy (see Policy → Identity) and is read again on every visit, so publishing a new policy changes it at once.

Email code

The customer types their email address and gets a six-digit code, valid for 10 minutes. A code is sent when the address is on file: an exact match for one of your customers in a live payment connection, or an address with requests on the site. Every address gets the same answer, so the page reveals nothing about who your customers are. An address shared by several customers in one payment connection signs in nobody there.

A code sign-in shows the customer's accounts in every connection where their address matches, for example both your US and your EU Stripe accounts.

The "My account" link

If customers sign in on your site, give them a My account link that opens the portal already signed in. Your server sends a signed-in customer to:

{Portal address}/start?token={a fresh token}

The token is the same signed token the chat widget takes (see Widget and identity → Signed token): an HS256 JWT signed with your widget signing secret, valid for at most one hour, naming the customer in sub and, optionally, their payment connection in connection. One token opens one session, so create a new one each time the customer clicks. Never create the token in the browser.

A token session shows only the customer the token names, in that one payment connection. It is never widened to other accounts with the same email address: your login proves who the customer is on your site, not that they own the mailbox. A customer with accounts in several connections can sign in with the email code to see them all.

When your policy requires a signed token, the portal has no code form: customers sign in only through your My account link. A code or an email link still lets them follow requests they sent through your form, but never shows their payments or subscriptions and never starts an action.

A session lasts 7 days from the customer's last visit, and at most 30 days. Refunds, cancellations and the assistant also need a sign-in from the last 24 hours; after that the customer can still read, and is asked to sign in again before acting. Your My account link always carries a fresh token.

What customers see

Overview: their subscription, latest payment, open requests and recent payments.
Payments: every payment of theirs, newest first, with the amount, date, card brand and last 4 digits, your description, and the refund status (refunded, partly refunded, refund in progress, refund reversed), including refunds you made outside Chargeless.
Subscriptions: the plan, price and interval, the next payment date, the status (active, trial, payment due, cancellation scheduled, ended) and the subscription's payments. A failed renewal shows only its date, amount, "Payment failed" and the card. A customer who has never had a subscription with you sees nothing about subscriptions: no Subscriptions page or menu entry, no subscription topic in a new request, no cancellation suggestion from the assistant. A customer whose subscriptions have all ended still sees them.
Requests: the requests they sent through your form or opened in the portal, and the conversations the assistant passed to your team, with a status filter. A request page shows the conversation and your team's replies.

Customers never see a full card number, a decline code, an id from your payment system, the name of a payment connection, your internal notes, suggested replies, decision details or your policy. A record that is not theirs looks exactly like one that does not exist.

The portal speaks English, Turkish, Spanish, Portuguese (Brazil), French, Arabic (right to left) and Russian. Everything except the assistant works without JavaScript.

What customers can do

Get help with a payment, or a refund

On a payment's page, the Get help with this payment panel first asks what the customer needs: a question about the payment, a payment they don't recognise, a double charge, a problem with the order or the service, a refund, or something else. Only refund requests lead to a refund:

I was charged twice and I don't recognise this payment go straight to the refund check below. When the payment paid for a subscription, the unrecognised case says so, with a link to it.
I want a refund asks why (Charged twice, I don't recognise this charge, I forgot to cancel, Not as described, A problem with the service, Other), then checks.
A problem with my order or the service offers the assistant and a request to your team first, and below them "I still want a refund" with two reasons.
A question and something else offer the assistant and a request to your team about this payment. No refund is checked.

For a refund, the portal then shows what your policy would do, for example "€29.00 can be refunded" with the end of the refund window, and asks them to confirm. The amount is the whole amount still refundable on that payment; customers cannot choose a smaller amount yet.

If the policy would not refund automatically, the panel says so and offers Ask the team instead of Confirm. After Confirm the customer sees the outcome: refunded, in progress, declined with the reason, or passed to your team, in which case the request appears under Requests.

Pressing Confirm twice, or in two tabs or on two devices, gives one decision. A customer can ask again for the same payment only after a refusal or a failed refund, at most 3 times a day. Operational reasons, such as an emergency stop, are never named to customers: they read "Automatic refunds and cancellations are not available right now".

Cancel a subscription

On a subscription, Cancel subscription shows what will happen and asks for confirmation. A cancellation takes effect now, not at the end of the paid period. If your policy refunds the last payment with a cancellation, the panel says so and shows the amount.

Write a request

New request lets the customer write to you about a payment, a subscription or something else, optionally naming the payment or subscription. The request is a ticket that the automation answers first and hands to your team when it cannot settle it (see Tickets). Your team's replies show on the request page and also go to the customer by email. A customer can open 5 requests an hour.

Ask the assistant

The overview has the same assistant as your chat widget, already signed in: it never asks who the customer is. It can look up their payments and subscriptions and help with a refund or a cancellation; as in the widget, it offers a choice and only the customer's Confirm starts anything. When it passes a conversation to your team, the customer follows it under Requests. Signing out ends the conversation.

Decisions follow your policy

A portal refund or cancellation goes through the same checks as one asked for in the chat: identity, the refund window, amounts per currency, your custom rules, the refundable remainder, the velocity limits, the circuit breaker, every emergency stop and each payment connection's state. Each decision records your policy version and the facts it used.

A portal request is decided as a chat request in every step. A custom rule on Request comes from cannot tell the portal from the chat; a rule comparing it with the portal is refused when you publish.
The per-customer refund limit is shared by the chat, your form and the portal, and counts all of the customer's verified accounts.
The email code and the email link count wherever your policy accepts the email code.
The matched identity level never applies in the portal.
Nothing in the portal can be approved beyond your policy. Only your team can go beyond it, from a ticket.

Your logo and colours

Your help site can show your logo and your brand colour instead of the workspace name and Chargeless's green. Open Settings → Help Site and Portal → Help Site Look (a role that manages the widget). It works before you go live, and the preview shows the result in light and dark.

Logo: choose Upload Logo and pick a PNG, JPEG, WebP or SVG. Your browser fits it inside 960 × 240 pixels and sends it as a PNG of at most 190 KiB, so only its pixels leave your computer. The help site shows it in the header and on the sign-in page, with your workspace name as its text for screen readers. Remove Logo shows the name again and deletes the stored image.
Colour: one colour for buttons, links and highlights. It must be dark enough for white text on it and for itself as text on the page (4.5:1); the field says at once when a colour is too light, and Save stays off until it is not. The dark-mode shade is worked out for you.
Appearance: Follow device (the default), Light or Dark. With Follow device, customers can also pick System, Light or Dark themselves from the appearance menu at the top of every page; choosing Light or Dark here sets the look for everyone and hides that menu.
Corners: Rounded (the default), Soft or Square.

Reset to Chargeless Defaults puts the colour, appearance and corners back. Each change shows on the next page customers open and is recorded in the Audit Log. Emails to your customers carry the logo too, in place of your workspace name; a mail app that blocks images shows the name.

What your team sees

Action Log and cases: the portal's decisions with the source "Customer portal" and the case types "Portal refund" and "Portal cancellation", each with its decision story.
Tickets: the channel "Customer portal", with where each ticket came from: a request the customer wrote, a refund or cancellation the policy handed to your team (with a note stating what was asked and the payment linked), or a chat with the portal's assistant. Filter the queue by the channel.
Handoffs go where your handoff destination says. With Zendesk as the destination, your team answers in Zendesk, and the request page tells the customer that replies come by email.
Webhooks: the events you already receive (handoff.requested, action.executed, action.failed, refund.reversed, ticket.handed_to_team, ticket.status_changed) carry portal as the source, channel or case type (see the webhook reference).
Automation Value counts each portal refund or cancellation, and each written request, as one contact of the channel "Customer portal"; a conversation with the assistant counts as a chat.

Turning it off

Choose Turn the Customer Portal Off. Your help site goes back to showing customers only their requests at once: signed-in customers can no longer see payments or subscriptions, ask for refunds or cancellations, or use the assistant, and an assistant conversation in progress ends. Requests they already opened stay with your team, and their sessions stay signed in for the request page.