← All work Say hello
TIPTIP · PAYMENTS · 2025 · CASE STUDY

Harsya Payment Integration

Adding a second card gateway to TipTip’s checkout, so card payments cost less and keep working when one gateway fails.

ROLESole Product Designer, Payments
TEAMPM, Backend, QA
TIMELINEQ3 2025
PLATFORMMobile app & web
Harsya credit card checkout screens on phones
2card gateways, switchable per ticket SKU from an internal tool
10payment failure states, each with a plain-language reason
3confirmation channels: email, push and in-app
01THE PROBLEM

One gateway, one point of failure.

Card payments were a major revenue driver for TipTip, and one of its biggest cost and risk factors. Every card payment ran through a single gateway.

When an incident took away our cheaper processing route, every card payment fell back to a more expensive setup, with no backup. It exposed two weak spots:

Financial inefficiencyHigh processing fees were cutting into profit margins on every card transaction.
System fragilityRelying on one gateway meant one outage could stop card payments entirely.
02THE GOAL

Cheaper, sturdier, and invisible to buyers.

  • Lower costs with a second gateway at a better rate
  • Reliability: switch instantly between gateways, with no downtime
  • Same checkout for buyers, whichever gateway runs behind it
  • Clear errors, so buyers know what went wrong and what to do next
03APPROACH

Map every state, from card input to confirmation.

As the sole designer in the Payments squad, I owned the end-to-end card journey and worked closely with the PM, backend engineers and QA.

Map the full journeyEvery step and state, from entering a card to success or failure.
Keep it consistentMeet the new gateway’s technical rules while matching the existing checkout.
Design the errorsA visual system where every failure reason has a clear, human explanation.
04CONSTRAINTS

The new gateway worked very differently.

The existing gateway answered instantly and had retry built in. Harsya didn’t, so the design had to absorb the difference:

Delayed verificationPayment results arrive later through a callback, not right away.
Raw error codesFailures come back as technical codes buyers can’t act on.
No switching mid-checkoutBuyers can’t change payment method once a card payment starts.
05KEY DECISIONS

What I designed, and why.

DECISION 01

Buyers shouldn’t notice the gateway changed

The card form, saved card and error states follow the same layout and flow as the existing checkout, even where Harsya’s rules differ. Switching gateways never means relearning checkout.

Select credit card, card details form, saved card and error state screens
Selecting a card, entering details, the saved card and an error state.
DECISION 02

Wait honestly, then say exactly what went wrong

A Verifying Payment screen covers the delay while we wait for the callback. If one arrives, the buyer lands on the specific reason, like an expired card or not enough limit. If none arrives, a general error removes the uncertainty.

Verifying payment screen and ten payment error states
Verifying Payment, one general error and nine specific reasons, each mapped from a gateway code.
DECISION 03

Two clear ways out after a failure

Since buyers can’t switch method mid-checkout, a failed payment offers Change Card, with details pre-filled for a quick retry, or Cancel Order to start again with another method. Success goes straight to the ticket.

Card failure, change card, order canceled, payment success and ticket purchased screens
Card failure, change card, order canceled, success and the purchased ticket.
DECISION 04

Keep buyers informed outside the app

Because verification can take a moment, email, push and in-app notifications carry the payment status and ticket details, so buyers aren’t left wondering.

Email, push and in-app notifications about payment status
Email, push and in-app notifications.
DECISION 05

Switch gateways per SKU, not per platform

An internal tool lets the team choose the active gateway for each ticket SKU. That allowed a controlled rollout, and a fast reroute whenever a gateway has trouble.

06IMPACT

Lower fees, fewer failed payments, no single point of failure.

  • Lower card processing fees on every transaction, with room to negotiate as volume grows
  • Higher payment success rate after the new flow went live
  • Business continuity: card payments can be rerouted through another gateway at any time
  • Clearer errors and faster confirmation, consistent across mobile and web

Exact fees and success rates stay confidential.

07REFLECTION

Constraints are design material too.

Lining up UI states with asynchronous payment logic only worked because PM, backend and QA were in the room from the start.

The hardest part wasn’t the happy path. It was adapting to the gateway’s limits while keeping checkout feeling exactly the same for buyers.

NEXT CASE STUDY