KDV Online - IPS (Instant Payment System) Checkout for a Non-Standard Counterparty Type
Product Designer
Product
The Trade Agent Personal Account (LK TA) runs in 10+ CIS countries, each with its own local payment integration. In Russia, the platform's largest market (42% of orders, 40% of revenue), it processes 190,000-270,000 orders a month (2025) - this is the market where the IPS checkout flow launched.
My role
Designed the full IPS checkout flow, including multi-order sequencing, QR re-entry, and three distinct failure states
Wrote the copy and defined the visual tone for payment success, cancellation, and network-failure screens
Results
~250 orders/month through the IPS channel within the first quarter - from zero before launch
Shipped a payment flow with 3 clearly differentiated outcome states instead of a single generic error
Multi-order checkout pays each shipment separately without losing progress if one fails
A buyer with no way to pay
Owners of street-food stalls - shawarma, fast food - who buy mayonnaise in 10-liter containers straight from the supplier. In the accounting system, they're registered as individuals, not legal entities: no business bank account, no way to pay on credit terms.
These buyers simply couldn't pay for an order through the app before. Standard invoice payment didn't work for them, and IPS wasn't available for legal-entity accounts. In practice, this meant one of two things: either the agent didn't sell to this location through the app at all, or the payment happened in cash, off the books, with no record in the system.
CJM · the buyer's journey before IPS existed for this segment.
The task wasn't "add another payment method" - it was opening up a sales channel that didn't exist for this segment at all.
What the flow looks like when everything goes right
The agent logs in under the location, builds a cart from the standard catalog, and places the order - the only difference is that the payment method is fixed as "Instant Payment System," with no choice to make. After placing the order, a screen appears with a QR code and a timer; the buyer scans it and pays.
The full path on one diagram - checkout → QR with timer → one of three final screens. Localized for portfolio purposes.
A single "Error" screen didn't work
The first version took the simplest path: if payment failed - for any reason - show "Payment failed".
One message, three different causes. Localized for portfolio purposes.
The problem surfaced during a pre-release walkthrough, when I ran through the flow myself, simulating failure scenarios - letting the timer expire on purpose, cutting the connection mid-wait for a response from the payment gateway. By the third run, it was obvious: the same screen was saying the same thing in three situations that are completely different for the agent.
The agent is standing next to the buyer and has to explain what happened. Timer expired - just place the order again, nobody's at fault. No connection - check the network, it's not the buyer's or their bank's problem. Payment succeeded - that's not a failure at all, and a warning screen would be the wrong tone entirely. A single "failed" screen left the agent guessing and forced them to explain something vague to the buyer.
Success - "Payment successful."
Timer expired - "We'll update the order status shortly."
No connection - "Check your internet connection."
The three final states, up close. Localized for portfolio purposes.
One QR code for the whole multi-order seemed like the obvious fix
Wireframe: "Single QR for the full amount" (concept, not shipped). Rejected - the payment gateway generates a QR code tied to a single order's amount, not a group of orders. Building a "group payment" entity was out of scope for this task.
Sequential payment of two shipments, with independent failure handling for each. Localized for portfolio purposes.
We went with sequential payment instead - one QR code after another, but a failed payment on one shipment doesn't roll back one that already succeeded. The screen shows "Shipment 1 of 2 paid" and moves the agent straight to paying the second one separately.
Close the QR screen - does the order get cancelled?
We discussed a strict rule: close the QR modal without waiting for payment, and the order auto-cancels - the agent starts over. The logic made sense on paper: don't let unfinished payments sit around indefinitely.
Wireframe: "Auto-cancel on close" (concept, not shipped).
We rejected it, because an agent doesn't only close the screen when they've changed their mind. They get distracted, answer a call, or the buyer needs a minute to find their phone and remember their banking app password. A hard cancellation would have punished the agent for a normal work pause, not an actual decision to skip payment.
Instead, we allowed re-entry - the agent goes back to the order from the general list, and the modal shows whatever the current status actually is: still waiting, with time left; already paid; or cancelled, if the timer ran out. We handled the case where the response hadn't come back yet, too - an honest "Status will update shortly" instead of leaving the screen hanging in limbo.
entering the order from the list, reopening the QR modal with the current status. Localized for portfolio purposes.
Four edge cases checked before handoff to development
Agent and a substitute agent open the same order at once - whoever opens it second sees the current status, instead of a second QR code being generated.
Double-tapping "Pay" - a second tap is blocked until the backend responds.
Connection drops while the QR is being generated - a timeout leads to the same "couldn't verify status" screen as a connection failure later on.
Buyer scans an already-cancelled QR - the gateway correctly rejects a payment against a code whose order has already been cancelled.
Working with the team
Analysts defined the status model and the payment gateway integration; developers covered the front end across platforms. The product owner made the final call on all three decisions above, but based them on what I brought to the table - I came in with options, and an argument for why the simple version wouldn't hold up and what to do instead.
Summary
Each decision started with a simpler version that didn't survive contact with reality - a single error screen, a single QR code, auto-cancellation. The job wasn't to invent one universal answer, but to try the simple version at each point, see where it broke, and add just enough complexity to fix it.
This is a narrow segment, and we didn't run user interviews - decisions were validated by walking through scenarios before release, not through contact with real buyers in the field. This isn't a story about a growth metric. It's a story about opening a sales channel for a segment nobody had actually talked to before.