Founder & Head of Product

Why I built it

I founded EVX to solve a specific, well-defined market failure that I had observed from the acquiring side during my time at Paymentsense. High-risk merchants – gaming platforms, nutraceutical companies, supplement brands, adult content platforms – were being blanket-declined not because they were fraudulent, but because mainstream acquiring banks had no tooling to separate clean high-risk transaction flows from genuinely problematic ones. The result was that legitimate businesses with real revenue and real customers were either unbanked or forced to route through grey-area intermediaries who charged extractive rates precisely because no one else would serve them.

The market gap was not in credit risk assessment – it was in transaction routing intelligence. An acquiring bank’s risk appetite is not binary; it varies by transaction type, merchant category, time of day, card BIN country, and dozens of other signals. What did not exist was a gateway that could read those signals in real time and match each transaction to the acquirer most likely to approve it given its specific risk profile.

That is what I built.

The problem in numbers

The baseline authorisation rate for the merchant segment I targeted was 78%. That is not a marginal problem – it means that for every 100 card attempts, 22 customers hit a decline page and either abandon or go to a competitor. In a subscription business, a 78% authorisation rate on renewal attempts means that 22% of your entire subscriber base is involuntarily churning every billing cycle regardless of their intent to pay. The economics of that leakage are enormous.

Industry research and my own analysis of the acquiring data I had access to at Paymentsense showed that the primary cause was not actual fraud – it was routing: the wrong transaction was being sent to the wrong acquirer at the wrong time. Most high-risk gateways at the time used static routing rules: merchant A always goes to acquirer X. Static routing is simple to build, but it ignores the fact that acquirer X may have hit a risk concentration limit for that MCC at that hour and will soft-decline anything new, while acquirer Y has capacity and would approve the same transaction easily.

Architecture

The core of EVX is a dynamic routing engine. Every inbound transaction goes through a real-time risk scoring and routing decision before it touches an acquirer.

The routing engine is not a rules engine in the traditional sense. It evaluates each transaction against a live acquirer performance model – a rolling window of approval rate, decline reason distribution, and risk concentration per BIN country per MCC per time window – and selects the optimal acquirer for that specific transaction in that specific moment. The model updates continuously as new approval/decline data flows back from each acquirer.

The anti-fraud module I built in Iteration 2 addressed a specific type of transaction laundering that is common in the high-risk space: miscoded gambling transactions. Gambling MCC codes (7995) are blocked by most issuing banks, so merchants who want to process gambling revenue try to route it under adjacent MCCs – digital goods, entertainment, subscriptions. The pattern is detectable: the velocity of transactions per merchant per MCC combination, combined with BIN country analysis (jurisdictions with high gambling prevalence), produces a signal that a legitimate digital goods merchant would not generate. I implemented velocity rules and MCC arbitrage pattern recognition to detect this at the transaction level and flag or block accordingly, which reduced transaction laundering volumes by 19%.

The tech stack is PHP 8.4 / Laravel 12 (chosen for rapid development velocity and my existing proficiency), PostgreSQL as the persistent store, Laravel Passport for OAuth 2.0 merchant authentication, AWS KMS for encryption key management, Spatie RBAC for permission management, and Rapyd as the primary acquirer integration. 3-D Secure is implemented for card-not-present transactions where required by the issuing bank.

The dashboard: shipping in a weekend

Iteration 1 is worth describing in detail because it says something important about how I operate. When I launched the MVP routing engine, merchants had no visibility into what was happening to their transactions. They could see their bank balance going up, but they had no data on approval rate by BIN country, decline reason distribution, or time-of-day patterns that would tell them how to optimise their checkout flow. That is a real product gap – merchants who can see their decline reasons can fix things like card type acceptance, 3DS friction, or currency mismatch that are causing unnecessary declines.

I shipped a real-time transaction performance dashboard in a single weekend using Claude Code and Replit for AI-assisted development. It gives merchants a live view of: approval rate by time window, decline reason breakdown by code and category, BIN country performance, average transaction value, and total volume. This is not a polished design system product – it is an extremely functional operational tool, and it was in merchants’ hands within 48 hours of the decision to build it.

This approach – identify a specific operational gap, estimate the build time honestly, use every tool available to ship fast, and iterate from real usage – is a deliberate product philosophy, not a shortcut.

Iteration 3: reconciliation and settlement (in progress)

The third iteration of the product addresses what I believe is the most underserved pain point in the high-risk acquiring market: settlement reconciliation. The problem has three components. First, interchange reconciliation – understanding the true interchange rate applied to each transaction requires parsing Visa Settlement Service (VSS) and Mastercard Settlement files, which are structured differently and delivered on different cycles. Second, clearing cycle cut-off times – transactions that cross a cut-off boundary appear in different clearing batches, which creates balance discrepancies that are technically correct but practically confusing for merchants. Third, settlement delays – especially for cross-border transactions where the acquirer holds settlement until a risk threshold is cleared, merchants can have significant unreconciled float.

No existing gateway product I am aware of solves all three cleanly with a merchant-facing interface.

Economics

Authorisation rate improvement economics. Moving from a 78% to a 91% authorisation rate is not a 13 percentage point improvement – it is a 59% reduction in decline rate (22% to 9%). For a merchant processing £500K/month in attempted volume, that improvement recovers approximately £65,000/month in previously declined revenue that was otherwise lost. At a 2.5% gateway fee, that translates to approximately £1,625/month of additional gateway revenue per merchant, with negligible marginal cost because the routing logic is already running.

Fraud module value. A 19% reduction in transaction laundering volumes protects the gateway from scheme fines and risk exposure. Mastercard and Visa can impose fines of up to $25,000 per month on programmes that exceed MCC laundering thresholds, and persistent violations can result in programme termination. The value of the fraud module is therefore partly quantified in avoided fines and partly in the survival of the merchant relationships.

Engineering estimate and justification. EVX was built as a solo founder with AI-assisted development tools, which compresses the timeline significantly compared to a team build. The MVP routing engine and basic gateway was approximately 8–10 weeks of full-time build. The fraud module was an additional 4–6 weeks. For comparison, an industry-standard team estimate for a new payment gateway with a single acquirer integration and basic routing would be 3–4 months for a 2–3 person backend team – roughly equivalent to what was achieved solo using AI-assisted tooling. The dashboard (Iteration 1) was an explicit outlier: 48 hours, not because the scope was trivial, but because the scope was deliberately constrained to exactly what merchants needed to make operational decisions, nothing more.