How to accept Yape and Plin from your own system

“We want to accept Yape and Plin” is one of the most frequent requests for any Peruvian product, and it almost always starts from a wrong assumption: that they are two equivalent things integrated the same way. They are not. Yape is an app; Plin is not an app but a feature inside each bank’s own app. That structural difference decides how you charge with each — and explains why you “integrate” one and reach the other by another route.

The difference that explains everything

Yape is BCP’s own application, with its own user base. Plin is a shared feature living inside the apps of BBVA, Interbank, Scotiabank, Banbif and Pichincha. That is why a Yape integration exists and a “Plin integration” does not: you connect to Yape through a gateway, and you charge Plin users through the interoperable QR.

That asymmetry is worth pausing on, because it decides the scope of the project. Behind Yape there is a company with an API that gateways connect to; behind Plin there is no Plin company with a merchant portal, there are five banks sharing a feature. There is no key you could ask for to integrate it.

The practical consequence is that this article has two paths rather than one: for Yape, a gateway integration with its own limits; for Plin —and in fact for any wallet— the QR that the BCRP made interoperable, which settles the charge without integrating anything per app. Budgeting “integrate Yape and Plin” as two equivalent jobs means quoting two integrations where there is only one.

How you charge with Yape from your own system

You do not consume “the Yape API” directly: you reach it through a gateway —Culqi, Izipay or Niubiz— or, if your volume justifies it, with a direct integration with BCP. For most projects, the gateway is the sensible path.

If you already have a gateway, enabling Yape is usually adding one more payment method, not a separate project. We covered it in detail in the guide to integrating Culqi, where Yape lives alongside cards and PagoEfectivo in the same checkout.

One detail that surprises people and is worth knowing before quoting: in Culqi, charging with Yape is available exclusively through API integrations. If your plan was to solve everything with the checkout widget and add Yape later, that assumption falls — and part of the estimate falls with it.

The limits that decide whether Yape works for you

In Culqi’s integration, Yape payments are capped at S/ 2,000 per transaction and are only received in soles. Before designing anything, compare that ceiling with your average ticket: if you sell above it, Yape is not your main method — it is a complement.

This is the most useful filter in the article. An S/ 3,000 enrollment, a consulting engagement or a piece of equipment does not get paid through Yape — and discovering that after promising the feature is a scoping problem, not a coding one. For low tickets, on the other hand, it is close to mandatory: it is the most used method for everyday payments among younger Peruvian consumers, and not offering it costs sales.

And like any wallet, it is asynchronous: the customer confirms in their app and your system finds out via webhook, not through the browser response. If your integration leans on the browser return because it works with cards, Yape will break that assumption.

The interoperable QR: regulation that saves you work

Peru’s central bank mandated that payment services interoperate. Since March 2023 Yape and Plin transfer to each other, and since September of that year interoperability covers QR code payments. In practice: one QR instead of one per wallet.

This is one of those times when regulation simplifies engineering. The BCRP interoperability strategy advanced in phases —first between wallets, then immediate transfers and QR, then non-bank wallets— and the result for whoever is building is that you no longer need a code per app. The volume confirms it worked: the BCRP reported more than 186 million interoperable transactions a month as of mid-2025.

The design consequence: if your product displays a payment QR, think of it as an interoperable QR rather than “the Yape QR”. Your customer will pay from whichever app they prefer, and that should not force you to maintain parallel integrations.

What is coming: TAPP

The BCRP is preparing TAPP, a public digital payments platform expected in late 2026. It does not change what you have to build today, but it is a reason to design without tying yourself too tightly to one specific wallet.

The practical lesson is not to wait: it is to abstract. If your system models “payment method” as a concept rather than a fixed list of three names, adding the next rail —TAPP or another— will be one more row in a table instead of a refactor. It is the same criterion worth applying to any gateway: your operation should not depend on one particular company continuing to exist under the same terms.

Common mistakes

Two assumptions cause almost all the rework: that Yape and Plin integrate the same way, and that a wallet works for any ticket size. Neither one holds.

How we do it

We integrate gateways into production systems —Culqi and Niubiz— with the methods your operation needs, webhooks that do not duplicate and reconciliation solved.

We help you decide which methods to enable based on your ticket and your audience, and build it so that the real cost and the reconciliation do not surprise you later. If your product needs to charge the way Peru pays, let’s talk.

In summary

Yape and Plin are not two versions of the same thing: Yape is BCP’s app, integrated through a gateway, and Plin is a feature inside each bank’s app that you reach through the interoperable QR the central bank made mandatory. Before promising the method, look at the per-transaction cap —S/ 2,000 in Culqi’s integration, soles only— and hold it against your ticket. Design for asynchronous confirmation, use a single QR, and model the payment method as a concept: with TAPP on the horizon for late 2026, the only certainty is that there will be one more rail.