Credit/Debit Card
Captures card details for payment. The critical characteristic: the card number never reaches your application.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
Architect Panel → Commercial:
- Carts — the commerce features that use payments
Architect Panel → Integration & Connections:
- GoCardless Direct Debit — the direct debit alternative
How it works
The card details are entered into a form served by the payment provider, go directly to them, and what comes back to the platform is a reference. That reference can be used to take a payment; it is not a card number and cannot be turned into one.
Why this design and not another
Because handling card numbers directly brings the full weight of payment card compliance onto your application, your database, your backups and everybody with access to any of them. The scope of that is substantial and ongoing.
Tokenisation removes it. Your systems never see a card number, so there is no card number to protect, leak or account for. That is not a convenience — it is the difference between a manageable obligation and a serious one.
Never work around it
The rule that matters most here. Do not add a text field for a card number "temporarily", do not accept card details by e-mail into a notes field, and do not let anybody photograph a card into a file upload.
Each of those puts card data into your systems and undoes the entire arrangement — and it is usually done with good intentions by somebody solving an immediate problem.
What you can safely hold
The provider's reference, and typically enough to identify the card to its owner — the last few digits and the card type. That is what lets a customer recognise which card they used, and it is not sensitive in the way a full number is.
Use the provider’s form as given
Restyling a payment form to match your branding is a common request and needs care: anything that pulls card entry into your own page risks bringing card data with it. Where the provider offers supported customisation, use that rather than reimplementing.
Consider direct debit for recurring payments
For subscriptions and regular collection, direct debit is often a better fit than a stored card: no expiry to manage, lower fees, and a mandate that survives a card being replaced.
Cards expire and get reissued, which is a recurring cause of failed collections that direct debit does not have.
Test with the provider’s test cards
Never a real card. Providers supply numbers that exercise success, decline and error paths, and testing the decline path matters — it is what your customers will meet.
Worked example
A membership application takes joining payments by card, storing only the provider's reference and the last four digits so members recognise the card. Annual renewals moved to direct debit after a year in which reissued cards caused a run of failed collections in January.
Recommendations
- Never let a card number into your systems by any route.
- Store only the reference and enough to identify the card.
- Prefer direct debit for recurring collection.
- Test with the provider’s test cards, including declines.