Customers

Customers → Customers is everyone who has paid you, and anyone you have saved deliberately.

A customer record is created the first time somebody pays you, so the list fills itself. You do not have to maintain it for payments to work.

What a record holds

A name, contact details you have supplied, the payment identifiers they have used, and their history with you. Open one to see every transaction, refund and dispute attached to it — which is the fastest way to answer “has this person paid us before” and “did we already refund them”.

Why identifiers are masked

A saved payment identifier shows as 054****567, never in full. The complete value is not returned by the portal or by the API, in any response, to anyone.

That is deliberate and not adjustable. A full wallet number or account number in a list that any staff member can read, export and email is a data breach waiting for an ordinary mistake. The masked form is enough to confirm with a customer which account they used, which is what the list is for.

If you need the full value for a payment, you take it from the customer at the time — you do not read it back out of us.

Using a saved customer

Once a customer exists, a repeat payment can reference them by id instead of re-collecting their details. From the API that is customer.id on the charge instead of customer.identifier; in the portal it is picking them from the list.

Two things this does not do:

• It does not store a reusable payment instrument. A mobile money collection still prompts the customer’s handset, every time. Saving a customer saves you typing, not the customer’s consent.
• It does not merge duplicates. Somebody who pays from two different wallets is reasonably two sets of identifiers on one record if you created it that way, and two records if they arrived on their own.

Metadata is the better tool for your own identifiers

If you want your own customer id, account number or order reference attached to a payment, send it as metadata on the charge. It comes back unchanged on every read and on every webhook, which makes it the reliable way to tie our records to yours.

Do not put your own identifiers in the customer’s name field to make them searchable. It works until somebody sends that name to the customer in a receipt.

Data requests and deletion

A customer can ask what you hold about them, or ask for it to be deleted. Those requests are handled through us, because the records are in our system — contact [email protected] and we will run it through the platform’s data-request process, which has a deadline attached and a record of having been done.

Do not try to satisfy a deletion request by editing a customer record by hand. A transaction history cannot be deleted — we are required to keep it — and a half-deleted record is worse than an intact one for both you and the customer.