Client work · Payments infrastructure

Meridian

Alias · real name on request

Improving transaction success rate

Meridian is a licensed payment provider. Card and virtual account payments were failing at a rate that hurt both merchants and customers.

Two separate issues were driving this. Each payment method had a single default provider, so when that provider had issues, a customer's retry usually failed the same way. And the way payment status was being checked was slow and expensive to run at scale.

Sector
Payments infrastructure
Stack
Nuxt.js · TailwindCSS · WebSockets

Highlights

94–98%
Transaction success rate, up from the mid-to-high 70s

Approach

  1. 01

    Retry-aware routing

    I designed and built retry-aware routing. A failed attempt returns "failed" honestly. When the customer retries with the same payment method, the new attempt goes through an alternative provider for that method: cards move from the primary card processor to an alternate processor, and for bank transfer, if virtual account generation fails with the default partner bank, the retry goes to a second partner bank. Every attempt stays under one transaction reference, so merchants see one payment and one final webhook however many tries it took.

  2. 02

    Measuring the recovery

    Checkout logs distinguish "success", a payment that went through on the first attempt, from "success after failure", one that succeeded on a retry through another provider or method. That metric showed exactly how much the rerouting recovered.

  3. 03

    Sockets over polling

    Checkout was validating payment status by polling an endpoint every five to ten seconds. That covered virtual account transfers, and card payments going through 3D Secure, a flow where the transaction leaves checkout, goes to the issuing bank for authorization, and comes back. Polling that frequently was expensive in compute and added latency to an already multi-hop flow. I moved status updates to a WebSocket integration, so the server pushes the status the moment it changes instead of the client repeatedly asking.

  4. 04

    Polling kept as a fallback

    Reliability should not depend entirely on the socket connection, so polling stayed in place at a much lower frequency: around every thirty seconds instead of every five.

  5. 05

    More providers, more paths

    On the product side, in parallel, I integrated additional payment providers and processors. That gave retries more alternative providers to route through, and streamlined the overall flow.

Outcomes

  • Transaction success rate moved from the mid-to-high 70s to 94–98%.
  • That figure is measured more strictly than some other processors in the market: bank-side failures, like insufficient funds or an incorrect PIN, are still counted against it rather than excluded, which makes the gain harder to earn.
  • Direct card routing is in progress, expected to further improve success rates specifically on local transactions.

More work

All case studies