Plin
For a Peru-licensed operator, Plin is a secondary local online casino payment-method rail—deposit-strong, payout-weak—best run alongside Yape rather than in place of it, at an indicative ~3.44% + 18% IGV that tends higher once gambling risk is priced in. Plin is a Peruvian real-time, account-to-account wallet that moves money between banks in seconds via phone number or QR code, in Peruvian sol only. Built in 2020 by BBVA, Interbank, and Scotiabank and embedded inside their banking apps, it now serves around 6.5 million users. Treat it as one rail inside a broader Peruvian cashier, never a standalone gambling payment solution.
PLIN VS YAPE: WHERE DOES THE SECOND WALLET ADD VALUE?
For most Peru operators, Plin enters the conversation after Yape, not before it. That makes its business case unusually specific: operators need to understand what Plin adds once the country’s largest wallet is already available.
Three things matter most: access to Plin-native banking customers, the effect of Yape–Plin interoperability, and whether the chosen PSP actually supports Plin as a merchant payment method rather than simply listing “Peruvian wallets” in general.
The case for Plin rests on reach, player trust, and local economics:
Bank-app-native users
Plin is embedded across BBVA, Interbank, Scotiabank, BanBif, and other participating institutions. For players who naturally initiate online payments from their banking app, Plin can be a more intuitive checkout option than entering card details or switching to another wallet ecosystem. Transfers are PEN-denominated, authenticated inside the player’s bank environment, and confirmed in seconds.
Interoperability changes the coverage equation
Since BCRP-mandated interoperability between Yape and Plin began in 2023, accepting both no longer means buying access to two completely separate user bases. A Yape user can transfer to a Plin user and vice versa.
That reduces Plin’s exclusivity, but does not necessarily eliminate its value. Operators should look at actual cashier usage, conversion by banking segment, and gambling payment provider pricing rather than assuming that interoperability makes the second wallet redundant.
A2A economics without card authorization
Plin deposits move as domestic account-to-account transfers rather than card authorizations. There is no card PAN on the Plin leg, no issuer authorization decline in the card sense, and an executed push transfer does not carry normal card chargeback mechanics.
Indicative wallet acceptance is around 3.44% + IGV before gambling-specific pricing, so the useful comparison is Plin‘s cost and conversion against the operator’s existing Yape and local-card routes.
PLIN LIMITATIONS
The weaknesses are as decision-relevant as the strengths, and the first one is the reason Plin can never be a sole payment method for online casino.
Merchant support is less predictable than consumer reach. Public PSP integrations and gambling case studies in Peru skew toward Yape; Plin‘s people-to-merchant side is QR-based and has historically slowed due to the absence of open interoperability regulation, so Plin-specific (as opposed to Yape-only) gambling support must be confirmed provider by provider.
Native payouts are not the core Plin proposition. Plin is built and used as a deposit rail; there is no reliable, at-scale merchant-initiated Plin payout product for gambling. Operators almost always settle withdrawals via interbank bank transfers, creating a deposit–withdrawal asymmetry that must be engineered around rather than assumed away.
Interoperability can reduce incremental value. Yape–Plin interoperability improves the consumer experience but also weakens the argument that both wallets automatically deliver two distinct audiences. The second integration should earn its place through measurable conversion, coverage, resilience, or commercial upside.
Plin remains strictly local. Plin is Peru-only and PEN-only, with no native multi-currency or cross-border capability, so it cannot serve any other market in a multi-country footprint.
GR8_TECH can model the deposit-Plin/payout-transfer split so the payout gap doesn’t surface after launch—design your Plin payout path with GR8_TECH.
PLIN: MARKETS AND AVAILABILITY
Plin is a single-country rail, so its availability as a gambling method depends less on Plin itself than on two operator-side conditions: holding a Peruvian license, and securing a local PSP that will route Plin deposits for the gaming vertical. The table below is the practical picture.
| Market/GEO | Plin availability | Operator considerations |
| Peru | Consumer-ubiquitous across member banks; merchant acceptance real but skewed to QR/P2M; gambling access via local PSPs | Requires MINCETUR/DGJCMT authorization, a .pe-certified platform, PEN handling; pair with Yape + PagoEfectivo + cards; plan payouts via bank transfer. See Peru payments guide |
| Everywhere else | Not available | Use market-appropriate local rails instead |
Plin and Peru iGaming: what operators need to know
Before routing a single sol through Plin, an operator must clear Peru’s licensing and technical gates; the payment rail sits downstream. These three constraints most affect a Plin decision:
⚠️ Authorization is mandatory. Peru regulated remote gaming and remote sports betting under Law No. 31557 (2022), amended by Law No. 31806, and implemented by Supreme Decree No. 005-2023-MINCETUR, with the licensing regime in force from 10 February 2024. All operators and their B2B partners must be licensed or registered with MINCETUR; unlicensed operations face bans and heavy fines.
⚠️ Payment blocking is an active enforcement tool. The DGJCMT has instructed payment institutions to block transactions and services to illegal gambling operators—so an unlicensed operator can be cut off from local rails, including wallet flows.
⚠️ Tax and technical standards apply. Operators face a 12% tax on net winnings plus a Selective Consumption Tax on bets, and platforms must be certified by approved labs with real-time reporting to SUNAT and MINCETUR. A Peruvian domain and certified platform are prerequisites for any legal local payment routing.
DEPOSITS, WITHDRAWALS AND SETTLEMENT
Plin behaves as a fast, irrevocable deposit rail and a poor payout rail, and “settlement” is delivered by the PSP wrapping Plin rather than by Plin itself. The operator view is summarized below.
| Area | Operator view |
| Deposit availability | Strong—real-time A2A push from any member bank via phone number/QR |
| Withdrawal availability | Weak—no reliable at-scale merchant-initiated Plin payout for gambling; payouts run over interbank bank transfer |
| Typical deposit speed | Seconds; funds confirmable in real time for auto-credit |
| Typical withdrawal speed | Dependent on the bank-transfer payout path, not on Plin |
| Settlement model | Via local PSP; indicatively D+1 to D+3 to the operator, settlement currency PEN (or USD/EUR if a cross-border PSP converts) |
| Deposit-only risk | High—the ecosystem is deposit-centric; do not assume a symmetric Plin payout exists |
| Deposit–withdrawal asymmetry | Material—deposits via Plin, withdrawals via a separate rail; design and reconcile them independently |
| What depends on the setup | Whether the PSP supports Plin (vs Yape only) for gambling, reserve terms, settlement currency, and payer-identity data returned |
COSTS, LIMITS AND APPROVAL
The commercial picture below is indicative—a benchmark for modeling, not a quote—and should be confirmed with the chosen PSP.
| Item | Indicative value |
| MDR/transaction fee | ~3.44% + 18% IGV for standard wallet acceptance via a local iGaming payment gateway; higher for gambling risk category; payouts priced separately (bank-transfer path) |
| Rolling reserve | Common for gambling merchants; typically 5–10% held over a rolling period—confirm with PSP |
| Settlement cadence & currency | Indicatively D+1 to D+3; PEN locally, or USD/EUR via a cross-border PSP with FX applied |
| Deposit limits | Bounded by the player’s bank/app daily transfer limit and PSP caps rather than by Plin centrally; verify per bank |
| Withdrawal limits | Governed by the bank-transfer payout path and operator policy, not by Plin |
| Indicative approval rate | High for A2A push (funds either move or don’t); friction sits in player limits and manual-QR errors rather than issuer declines |
| FX/repatriation | If settlement currency ≠ operator currency, a cross-border PSP converts PEN→USD/EUR; factor FX spread and prefunding into unit economics |
DO YOU NEED BOTH PLIN AND YAPE?
For a Peru operator, the most useful question is not what other rails should accompany it. It is whether adding Plin beside Yape produces enough incremental value to justify another commercial and operational relationship.
| If this is true… | Plin is more likely to be worth adding |
| A meaningful share of players bank with Plin-participating institutions | Yes—native bank-app familiarity may improve checkout preference |
| Yape is already live, but wallet conversion still leaves identifiable gaps | Yes—marginal implementation cost is lower |
| The PSP exposes both wallets under the same integration and reconciliation layer | Yes—marginal implementation cost is lower |
| Plin requires a separate provider, reporting flow, and commercial minimum | Run the economics first |
| Yape already captures almost all wallet demand | Incremental value may be limited |
| The objective is better payouts | No—Plin does not solve that problem |
Interoperability makes this a measurement problem rather than a checklist problem. Operators should compare approval, conversion, deposit value, and total cost between Plin and Yape instead of adding both simply because both are popular Peruvian wallets.
💭GR8_TECH’s role here is less about connecting “another gambling payment method” and more about giving the operator enough routing and transaction data to determine whether Plin creates genuine incremental conversion or simply duplicates an existing Yape path.
HOW OPERATORS ACCESS PLIN
No gambling-grade Plin merchant API is sold directly to operators, so access always runs through an intermediary. The four practical points below cover how the connection, data, and onboarding actually work.
- Access routes: Via a local PSP/gateway (hosted checkout or API) that exposes Plin deposits, or via an orchestrator that aggregates Plin, Yape, PagoEfectivo, and cards behind one integration. A single-PSP integration is realistically a few dev-weeks; less if routed through existing orchestration.
- Providers by GEO (Peru): Local PSPs/acquirers commonly cited for Peruvian wallets include Culqi, Niubiz, and Izipay; cross-border LatAm PSPs with Peru wallet coverage include dLocal, EBANX, Kushki, Mercado Pago, and Rapyd.
- Reconciliation & reporting: Expect a payer reference, transaction ID, real-time deposit status/webhook, and a PSP settlement report. Because Plin identifies users by phone number, confirm what payer-identity data is returned for account-ownership matching and how QR/phone deposits are attributed to the correct player.
- Onboarding/underwriting: Realistic go-live is weeks to a couple of months, gated by KYB/underwriting. Prepare the MINCETUR authorization, ownership documents, target-market and flow diagrams, and processing history; gambling merchants should expect a reserve discussion.
MOST COMMON FRAUD AND RISKS
Plin’s defining fraud problem is not stolen card data; it is who actually owns the bank account behind a phone-number payment. That matters even more because withdrawals normally leave through a different rail.
- Third-party funding/ownership mismatch. Plin‘s phone-number model makes it easy for a deposit to come from an account that isn’t the player’s—squarely the operator’s KYC/AML problem. Enforce name/account matching against the registered player.
- Withdrawal-destination substitution. Because payouts run over a separate bank-transfer rail, verify the payout destination belongs to the verified player before releasing funds.
- Manual-QR / phone-number substitution. Where deposits rely on a displayed QR or phone number that rotates for security, a spoofed or stale destination can divert funds. Prefer PSP-tokenized, dynamically generated deposit references over hand-keyed transfers.
- First-party / friendly claims and refund abuse. A2A push is irrevocable and carries no chargeback (good for dispute cost), but players may pursue bank-side complaints or claim non-receipt; keep immutable transaction evidence.
- Mule accounts / circular funding and bonus abuse. Fast, low-friction A2A deposits are attractive for layering and multi-account bonus abuse; device, behavioral, and velocity checks remain the operator’s responsibility.
COMPLIANCE
A PSP wrapping Plin reduces the operator’s payment workload but does not transfer the operator’s regulatory obligations; in Peru’s licensed framework, the operator keeps KYC/AML, responsible gambling, and reporting duties. The split below shows where each responsibility lands.
| Domain | Provider position | Operator implication |
| PCI DSS | A2A push means no card PAN in scope on the deposit leg; PSP handles any card legs | Card-complementary casino payment methods still bring PCI scope; confirm PSP AOC |
| SCA/Authentication | Payment authenticated inside the player’s bank app | Rely on bank-app auth for the transfer; still authenticate the player at the operator level |
| AML & KYC | PSP may offer screening tooling | Operator retains full KYC/AML under MINCETUR rules; match depositor to registered player |
| Account ownership | Plin identifies by phone number, not by verified name-to-account at the operator | Operator must enforce ownership matching to prevent third-party funding |
| Responsible gambling | Not a provider function | Operator implements deposit limits, self-exclusion, and RG tooling per Peruvian law |
| Data protection | PSP processes payment data | Comply with Peru’s Personal Data Protection Law (Law 29733) for player and transaction data |
| Transaction monitoring | PSP provides deposit data/webhooks | Operator monitors for structuring, mule, and circular-funding patterns |
| Local gambling-payment restrictions | Local PSPs route only for authorized operators | Unlicensed operators risk DGJCMT-directed payment blocking |
| Recordkeeping & reporting | PSP settlement reports feed reconciliation | Operator meets real-time reporting obligations to SUNAT and MINCETUR |
| Sanctions screening | PSP may screen | Operator retains sanctions/PEP screening responsibility |
| Interoperability / closed-loop rules | Governed by BCRP; Yape–Plin interoperable since 2023 | Design for evolving BCRP interoperability phases rather than a fixed closed loop |
SHOULD PLIN BE IN YOUR PERU CASHIER?
Prioritize Plin if you already serve a meaningful Peru audience, your PSP exposes it with little incremental integration work, and you can identify additional conversion among Plin-participating bank users.
Treat it as optional if Yape already captures the overwhelming majority of wallet demand and Plin would require another casino payment provider, another reconciliation flow, or materially higher commercial overhead.
Do not add it to solve payouts. The practical withdrawal rail remains bank transfer.
Plin is less of a must-have standalone method than Yape and more of an optimization decision: measure the incremental wallet volume it creates after Yape is already in place.
Share
