Customers’ cards and recurring card charges
Cards kept so customers can be charged on a schedule they agreed to — shown only as brand and last four, sealed, and decrypted only to build the file for the bank.
A subscription, a monthly fee, an instalment plan: the customer agrees once and is charged on a schedule. Accounting → Card Payments holds the three parts — the cards, the agreements to charge them, and the batches sent to the bank. They are built the way the card industry’s security standard (PCI DSS) expects, so a card number is the one thing in TRANXACT nobody can read on a screen.
Cards
Add card takes the customer, the card number, the expiry, the name on the card and the billing postcode. From then on the card is shown only as its brand and last four digits, everywhere: on screen, in downloads, in ASK, in the audit trail.
- The number is sealed: encrypted with a key of its own (AES-256-GCM), and that key is itself encrypted with a key-encryption key the platform holds outside the database. A production installation without that key refuses to store a card at all.
- The security code (CVV or CVC), a PIN and the magnetic-stripe data are refused if they are sent, and never stored.
- The same card added twice is recognised, and kept once.
- Edit changes the expiry, the name on the card, the billing postcode or the status — never the number. A new card is a new card: add it, move the mandates to it, then delete the old one.
- Delete destroys the card’s own key, so the number cannot be recovered by anybody, and cancels the mandates on it.
Card mandates
A mandate is the customer’s agreement to be charged: the card, the amount and currency, how often (once, monthly, quarterly or yearly), the first charge date and, if there is one, the end date. What the customer agreed to, word for word, is required — that consent is what a disputed charge is answered with. A mandate can be paused, resumed or cancelled.
Card charge batches
- Charge due mandates makes one charge for every mandate due on the run date, and no more: running it again for the same date does not charge anybody twice.
- Export for the bank builds the file the acquirer or bank takes. It is the only place a card number is ever decrypted, it needs a grant of its own (Card Batch Export), and every export is recorded — without the card numbers. Upload the file, then delete your copy.
- The bank’s answer is recorded against each charge: settled, or failed.
Who may do what
Cards, Card Mandates, Card Charge Batches, Card Batch Export and Card API (external integrations) are all granted under Platform → Roles & Authorizations, like any other screen. ASK and agents are refused every card route, whatever role they run under.
Cards from your website: the card API
A website or app that takes a card can store it through the external API, so the number never passes through a person.
| Call | What it does |
|---|---|
| POST /api/accounting/card-api/v1/cards | Stores a card. Send an Idempotency-Key header: the same key sent twice stores the card once and returns the same answer. |
| GET /api/accounting/card-api/v1/cards | The cards, masked — brand and last four. |
| PATCH …/cards/{id} | The expiry, name on card, billing postcode or status. Never the number. |
| DELETE …/cards/{id} | Destroys the card, as Delete does. |
| /api/accounting/card-api/v1/mandates | Creates and reads mandates, with an Idempotency-Key in the same way. |
- The caller signs in with a service account’s token (see Service accounts), and that service account’s role needs an explicit grant on Card API (external integrations). A role with everything, or an administrator role, does not count: the grant has to be given by name.
- In production the calls are accepted over HTTPS only.
- Calls are rate-limited per account, and a run of declined or invalid cards — the pattern of somebody testing stolen numbers — locks the caller out.