A payment record lives everywhere a system stores, transforms, routes, reconciles, or exposes it. Before answering an enterprise questionnaire, trace the record from the customer’s payment screen through every processor, database, backup, dashboard, support tool, and jurisdiction it touches.
In 1854, physician John Snow faced a similarly awkward question in Soho, London: where did cholera actually come from? The accepted explanations did not match the pattern he could see. People were dying, the mechanism remained disputed, and Snow had to follow individual cases back to a shared point.
A contract call becomes a data audit
At 9:14 on Tuesday morning, a Ghanaian SaaS founder opened what he expected to be the next step toward a Nigerian enterprise contract. Instead, the prospective customer had sent a security questionnaire.
One question stopped the call preparation: Where does the payment record live?
The founder’s first answer was easy. Payments went through the processor, and the application stored the result.
Then the question widened.
The processor held transaction data. The application database stored a payment status and reference. A background job retried failed updates. An internal dashboard displayed the customer’s payment history. Support staff could search for a transaction. Logs might contain identifiers. Backups preserved older copies. Finance exported records for reconciliation.
The payment had happened once. Its record had multiplied.
That distinction matters when a Nigerian company evaluates software built by a Ghanaian team using infrastructure owned elsewhere. The customer is asking where its information can travel, who can see it, and which systems must be checked when something goes wrong.
A provider name alone cannot answer those questions.
Follow the record, system by system
Snow’s method was practical. He mapped cholera deaths around the Broad Street pump and investigated how affected households obtained water. His work did not settle every scientific argument at once, but it connected scattered cases to a common source strongly enough for local officials to remove the pump handle.
The US Centers for Disease Control and Prevention recounts the Broad Street investigation as a foundational example of field epidemiology. Snow made the hidden route visible by tracing outcomes back through the system.
A payment-data review needs the same discipline.
Start with one ordinary transaction. Follow it from the browser or mobile app to the payment processor. Record what returns to your product, what your database keeps, and what appears in logs. Continue through webhooks, queues, analytics, customer support, finance exports, backups, and error-monitoring tools.
For each stop, write down:
- which fields arrive;
- why the system needs them;
- how long they remain;
- who can access them;
- where the provider processes or stores them;
- what happens when the customer requests correction or deletion.
This exercise often exposes assumptions hidden inside shipped code. A developer may have logged the full processor response while debugging an early release. A spreadsheet used for reconciliation may still sit outside the main access controls. A support tool may retain a transaction identifier after the account has been deleted.
That is the same class of problem described in the shared spreadsheet the demo didn’t account for. The overlooked system becomes important precisely because nobody included it in the original diagram.
Jurisdiction follows the vendors
The founder’s second difficulty was geography. His company operated from Ghana. The prospective customer was in Nigeria. Several software providers sat outside both countries.
A useful answer therefore needed more than “hosted in the cloud.” It needed a record of each provider, the function it performed, the data it received, and the regions or jurisdictions involved.
This does not require a polished compliance programme before the first enterprise conversation. It requires an honest inventory.
If the team does not know where a vendor processes data, “to be confirmed with provider” is better than a confident guess. If an old export cannot yet be deleted reliably, record the gap and assign an owner. If logs contain more payment information than engineers need, reduce what gets logged before writing a longer policy around it.
The questionnaire is doing useful product work. It is testing whether the architecture the team shipped matches the story the company tells customers.
The same principle applies to AI features. One visible action can trigger several model calls, monitoring events, and stored outputs. The model calls hidden behind one AI feature examines the cost side of that chain. Payment reviews reveal the data-responsibility side.
Build the map before the next questionnaire
By the time John Snow marked cases on his map, the individual deaths were already known. The value came from showing how they connected.
A founder should do the same before the next enterprise prospect asks. Choose one payment and trace its complete path. Turn the result into a living data map linked to the systems the team actually uses. Review it when a processor, analytics tool, support platform, or hosting configuration changes.
Then prepare a short customer-facing version. Name the categories of providers involved, explain what each receives, identify unresolved items, and state who owns the follow-up. Keep internal credentials, tokens, and unnecessary implementation details out of it.
The next time “Where does the payment record live?” appears at 9:14 on a Tuesday morning, the answer should come from the map. Not memory.
Comments
No comments yet.