Payment solutions development

Scope sets the timeline: the number of acceptance surfaces, the number of providers and methods, and whether refunds, chargebacks, payouts and settlement reconciliation are in scope. As reference points from our own work, an Android payment SDK for payabl. reached production in one month, and a credit PWA for $lana (Monetech) went live with two KYC providers and full reporting in five months. Discovery turns your scope into a dated plan before you commit.

Yes, and it is usually the right call. We work with the acquirer or PSP you already operate and build inside your existing architecture. If the provider is genuinely the constraint - on cost, on approval rate or on a market it cannot reach - we will say so, and an orchestration layer that keeps them as one route among several is often a better answer than replacing them.

By keeping card data out of your systems wherever the architecture allows - tokenisation through your acquirer or payment provider, so your platform holds a token and never a PAN, and your PCI DSS scope stays as small as possible. Where a token vault is genuinely required, we isolate it as a narrow service with its own access control and audit trail, and document exactly what is stored and who can reach it.

The ones where a person is already reading data and forming a judgement: fraud and risk scoring, decline analysis that turns provider response codes into a retry decision worth making, and reconciliation matching where a settlement file and your own records disagree over a rounding rule nobody documented. Each of those has a fallback and a reviewer. What it should not do is quietly decide whether a customer's payment goes through with no route to a human and no record of why, which becomes a customer-relations problem long before it becomes a regulatory one.

It depends what you touch. Keep card data entirely with the provider and your PCI DSS obligation is a short self-assessment; hold a PAN or run your own vault and it becomes a full assessment with an assessor on site. That single architectural choice moves the compliance cost more than anything else on the project. On the operational side a regulated buyer will look for resilience testing rather than a certificate: Articles 24 to 26 of DORA, Regulation (EU) 2022/2554, put digital operational resilience testing on a defined footing, and platforms supporting critical functions are expected to evidence it.

Keep three things in your hands from the start. The repository and the pipeline, so nothing ships that your team cannot read. The provider relationships and the credentials, so the integration is yours rather than the supplier's. And the reconciliation, because whoever can prove the day balanced controls the platform in practice. We build inside your stack on that basis and hand over the state machine, the runbooks and the reconciliation tooling, so an outsourced build does not quietly become an outsourced dependency.

Direction and obligation. A merchant platform accepts money, and its worst day is a failed checkout. A bank moves money on behalf of customers, so the same flow carries authentication duties, scheme and rail cut-off times, sanctions and fraud checks inside the path, and a reporting obligation attached to every movement. The engineering consequence is that the bank's version needs an auditable state machine and a reconciliation position at all times, not merely an eventual one. Building the merchant shape and adding the bank obligations later is the expensive order.