Do we need a payment licence to build this?
It depends on whether you hold or control customer funds. If money flows directly from the payer to a licensed provider and then to your bank account, you are typically not holding funds and licensing may not apply. If you hold balances on behalf of others, schedule payouts, or move money between users, you are in regulated territory in most jurisdictions. This is a legal question and it needs a qualified adviser in your market. We build to whichever answer you get, and we will tell you plainly when a requirement you have described sounds like it crosses that line.
Is AgileTech PCI DSS certified?
No. AgileTech holds ISO 9001:2015 and ISO 27001:2013 certifications, and those are the only certifications we claim. PCI DSS applies to entities that store, process, or transmit card data, and the attestation belongs to you and your providers. Our contribution is engineering that keeps your PCI scope as small as possible, usually by ensuring raw card data never touches your systems, and documentation of the data flows your assessor will request.
Should we integrate one provider or several?
Start with one, but build the abstraction that allows several. Almost every business that scales eventually adds a second provider, for cost, for a market the first does not serve well, or for resilience after an outage. The cost of designing for that at the start is modest. The cost of retrofitting it once provider specific assumptions have spread through the codebase is not.
Why does the double entry ledger matter so much?
Because a stored balance you edit cannot be audited. If a balance is a single number that gets updated, and it turns out wrong, there is no way to determine when it went wrong or why. With an immutable double entry ledger, the balance is the sum of entries, every entry has a cause, and a discrepancy points to a specific movement on a specific date. It also makes corrections safe, because you post a reversing entry rather than editing history.
How do you prevent double charges?
Idempotency keys on every money moving request, enforced at the platform boundary. The caller generates a key, and a repeated request with the same key returns the original outcome instead of charging again. This covers the common causes: a user tapping twice, a mobile client retrying after a timeout, and a queue redelivering a message. Provider level idempotency is used as well where offered, but we never rely on it alone.
What happens when a provider goes down mid transaction?
The dangerous case is a timeout after the provider has authorised but before you received the response, because the money may have moved without your knowing. The platform records the attempt before making the call, then resolves the unknown state by querying the provider and by reconciliation, rather than assuming failure. Assuming failure and retrying without idempotency is exactly how duplicate charges happen.
How long does a payment platform take to build?
A single provider, single currency, card only platform with a proper ledger and reconciliation is usually a matter of a few months. Multiple providers, multiple currencies, wallets, local rails, marketplace splits, and payouts extend that considerably, and the extension is mostly in reconciliation and edge case handling rather than in the acceptance flow. We will give you a range after the money mapping step, because that is the first point at which an estimate means anything.
Can you work with our existing gateway integration?
Yes, and it is often the right starting point. A common engagement is leaving the working acceptance path in place while we build the ledger, reconciliation, and reporting layer that was never completed, then progressively moving acceptance behind an orchestration interface. This sequences the risk sensibly, since the part that is losing you money is usually the accounting, not the checkout.
How do you handle multiple currencies?
Amounts are stored with their currency and never added together without an explicit conversion that records the rate, the source of the rate, and the time it was taken. Provider foreign exchange spreads are captured as their own ledger entries so the true cost is visible. Whether you settle in one currency or several is a business decision with real consequences for reconciliation, and we surface it early.
Who owns the code and the provider relationships?
You do, in both cases. Provider contracts are between you and the provider, so the commercial relationship and the funds flow are never routed through us. Source code, infrastructure definitions, and documentation are yours, delivered in your repositories. We build for handover, on the assumption that your team or another vendor will maintain this without us.
What do you need from us to start?
The methods, currencies, and markets you need, your expected and peak volumes, who bears fees, your settlement and payout expectations, and whether you hold funds on behalf of anyone. If you have an existing system, access to its data model and a recent settlement file tells us more in an hour than a week of meetings. From that we can produce the money map and a realistic plan.
