How a payment link project became a plan to recover abandoned Pix deposits, and why neither shipped.
01 · Context
KTO was a licensed betting platform in Brazil, and almost every deposit ran on Pix, the instant payment system most Brazilians use every day. Every deposit also started in the same place, the cashier. A player who clicked a CRM campaign had to log in, navigate to the cashier, find the deposit option and only then pay. Support could not solve a deposit problem directly, and a player inactive for seven days had to sign in again before anything else.
Each of those steps lost intent. The company's target for the quarter was to raise same-day conversion from registration to first deposit from 40% to 60%, and the cashier was in the way of every journey that led there.
02 · Payment Link
The Payment Link proposed a different door: a link that opened a Pix deposit straight from wherever the player was. I prototyped three journeys. A CRM campaign whose "Deposit now" button opened the payment directly, a support agent who generated a link for a player stuck on a deposit, and a bet that needed R$100 when the balance had R$82, with a link for the difference.
I built the prototype with AI-assisted workflows in about two hours, work that would have taken days or weeks before, so the C-level could react to something concrete instead of a document. Alongside it, I mapped what the link page would need to earn trust: the player's name and registered bank accounts, an official KTO domain, and the legal entity receiving the payment. One hypothesis already pointed at the weak spot: a Pix QR code outside the app could feel suspicious however many badges it carried.
03 · The workshop
Before anyone committed engineering time, I ran a workshop with Payments, Product, CX, CRM and Compliance. People wrote alone first and discussed after, on two boards: where a deposit could start, and what could go wrong if payment links existed tomorrow.
The second board changed the project. The Lead Designer pointed out that anyone could fake a KTO email with a deposit link, which is exactly how Pix scams work in Brazil, and the team expected support contacts from players asking whether a page was real. I raised that detecting a player by CPF, the Brazilian tax ID, could let a stranger find out who had a KTO account. Another participant added that a player could dispute a link deposit by claiming they never authorized it.
The heaviest risk came from Compliance. A new ordinance from the betting regulator was expected, and it would ban pre-filling amounts on deposit screens. A link that opened the payment with the amount already set would fall right into it.
04 · The real problem
The data in the project's own business case pointed somewhere else. In the 30 days before the workshop, 83.75% of declined deposits were Pix QR codes that players generated and never paid, 168,527 of them. Among first deposits, the share was 75.6%.
Those players had already walked through the door the Payment Link wanted to open. They had chosen an amount and generated the code, and the deposit died between KTO and their bank app. The C-level had liked the concept, but Compliance's argument was strong enough to stop it early, and the Payments PM and I decided together to shelve the Payment Link before the ordinance came out. We moved to the bigger problem: recovering the Pix deposits players had already started. We called it Pix Multichannel.
05 · The data
Two explanations would have made the problem simple, and the data rejected both. Payment gateway friction did not hold, since PagSeguro and BTG, the two partner banks, showed almost identical abandonment. The idea that players who abandoned had given up for good failed too: 66% of them came back and paid within seven days.
Two patterns held. Abandonment peaked in the early morning, outside banking hours, and it rose steadily with the amount: one in three attempts above R$5,000 failed, which read as hesitation, not error. New players dropped off 2.6 times more often, for reasons the data could not confirm. Of all these causes, only one was something a message could fix: a valid QR code the player simply never went back to pay.
The sources also disagreed on the abandonment rate itself. Three reports gave three different numbers, so the Payments PM recommended the backend rate as the official KPI before anyone built a dashboard on the wrong one.
06 · Message timing
The partner banks set the clock. A Pix QR code stayed valid for up to 30 minutes at BTG and up to 60 at PagSeguro. The first plan split the recovery in two: real-time reminders while the code was still valid, and a long tail of emails for players whose code had already expired.
I dropped the long tail once I saw it could not move the metric we had chosen. The project measured the share of Pix codes that expired unpaid, and an email sent after expiry changes nothing in that number. Every message moved inside the validity window instead: a push 5 minutes after the player generated the code, an SMS 10 minutes later and an email 10 minutes after that, all before the shortest window closed.
The channel order followed what players opened, clicked and converted on most, from push to SMS to email. WhatsApp was out because Meta does not allow business profiles for betting, and Telegram was out because few players used it. Every message linked straight to the QR page after login, so the player landed on the code and not on the cashier.
Inside the product, I designed two more catches. A player who opened the app with an unfinished deposit saw a banner asking whether to continue or cancel it. A player who tapped logout with a pending Pix saw the amount and the exact time the code expired ("Your R$50 Pix is waiting for you. The code is valid until 17:10"), with paying as the main action and leaving as the other.
07 · Preferences
More messages needed more control for the player. I designed the preferences in two layers, what the player wanted to hear about (news and promotions, deposits and withdrawals, winning bets) and how (push, SMS or email), inside My Account's notification settings. Hiding the opt-out would have raised reach and broken Brazil's data protection law, so every channel kept a visible switch.
The trigger rules followed the same logic: Pix status, time since the code was generated, expiry, consent and previous attempts, so no player got a reminder for a code they could no longer pay or a channel they had turned off. The preferences depended on the channel model from the My Account revamp, which tied the two projects' timelines together.
08 · Outcome
Pix Multichannel went through grooming with engineering. Then a provisional measure on betting changed the company's priorities, and the project stopped before launch. Nothing shipped, so there is no result to report.
The proposal was honest about its reach from the start. It addressed the wrong channel and the wrong timing, the part of abandonment a message could fix, and it would not change the cognitive load of a first deposit or the exploratory behavior of new players. Those causes stayed on record as the next opportunities.
If I started again, I would start from the funnel, not the prototype. I built the Payment Link prototype before reading where the money was being lost. The abandonment data already existed, and it even appeared in my own business case for the link, but I didn't treat it as the problem until we moved to Pix Multichannel. The prototype took two hours; the real cost was a five-team workshop and the C-level's attention spent on a door players had already walked through.