Every certificate Marafiq issues carries a serial number and a QR code. Anyone, an employer or a training authority, can scan it and see on a public page that the certificate is real and who it was issued to. Nobody has to email Marafiq to ask.
That is what data integrity looks like from the customer's side: a claim your platform makes can be checked without trusting a person. From the inside, it means that when a customer disputes an invoice, a payment or a change to their account, you can answer in seconds with a record, not with a guess.
This post covers what a business platform should record, how to make those records trustworthy, and where the cost is.
Where trust breaks
Disputes and audit questions tend to come from the same few places:
Payments. "I paid, why does it say unpaid?" Someone marked it by hand, or a payment confirmation never arrived.
Changes nobody remembers. A price, a discount, a permission or a due date changed, and no one knows who changed it or when.
Documents. A certificate, contract or invoice that could have been edited after it was issued.
Totals that disagree. The report says one number, the accounting export another.
Each of these has a technical fix that is cheap when designed in from the start and expensive to add later.
What to record
You do not need to log everything. You need to log what someone may later question. This is the checklist we start from:
Who changed what, and when, for money, permissions and anything with a legal or contractual meaning: prices, discounts, invoices, roles, due dates. Keep the old value and the new one.
Payment events from the gateway, as received: created, succeeded, failed, refunded. Mark an order paid only when the gateway confirms it, never from the browser redirect.
Document versions. Once a document is issued, it is not edited. A correction is a new version that points to the old one.
Logins and access to sensitive data, especially for admin accounts.
Imports and bulk changes: which file, who ran it, how many records it touched.
Two rules make these records useful. Write them at the moment the change happens, in the same transaction as the change. And do not let normal users, including admins, edit or delete them from the interface.
Records customers can check themselves
The strongest form of trust is a record your customer can verify without you. On Marafiq, the training platform we built for facilities-management professionals, each PDF certificate has a serial number and a QR code that opens a public verification page. A certificate cannot be faked by editing a PDF, because the page shows what the platform issued.
The same idea applies elsewhere:
| Document | What the customer can check |
|---|---|
| Certificate or license | Serial number and public verification page |
| Invoice | A link to the invoice and its payment status in the portal |
| Contract or signed proposal | Who signed, when, and the exact version signed |
| Booking | Price and availability confirmed at the moment of payment |
On Omraty, a travel booking platform we built (it has not launched yet), hotel and flight availability is re-checked against the suppliers before payment is taken, so the price a customer pays is the price that was actually available.
Tests are part of integrity
Records only help if the code that writes them works every time. On Marafiq, about 940 automated tests run on every change, including the flows that issue certificates and take payments. When we change a dependency or add a feature, we know the same day whether those flows still behave.
If you are comparing teams, ask how they test the parts that touch money and documents. Our post on what to ask a software agency has the questions.
Privacy: record what you need, not everything
Integrity and privacy pull in different directions. An audit log that stores full personal data for every view grows fast and becomes a liability. A few rules keep the balance:
Log the identifier, not the content, unless the content is what may be disputed.
Set a retention period for each kind of record, based on legal and contractual needs.
Limit who can read the logs. Access to the audit trail is itself an action worth logging.
What it costs
Designed in from the first sprint, audit records, gateway-confirmed payments and versioned documents add little to a build: they are a few tables, a few rules, and tests around them. Added to an existing platform later, the cost is higher, because every place that changes money or permissions has to be found and changed, and old data has no history.
If you run a platform today, start with payments and permissions. Those are where disputes cost the most. Our post on what happens after your software launches covers how this fits into ongoing support.
Next step
Tell us which records your customers or auditors ask about most, and what you can show them today. We will reply within one business day with what we would add first. Request a quote.