# Payment Stack Recommendation: Teleton Peru Micro-Raffle (Rifa): Culqi Primary, Mercado Pago Fallback

## Summary
For a mobile-first Peruvian charity micro-raffle with S/5 to roughly S/30 tickets and social-media-driven volume spikes, the binding constraint is not the percentage fee but the fixed minimum-per-transaction fee, which is fatal on a single S/5 ticket. I recommend Culqi as the PRIMARY provider (it is Peru-native, BCP-backed, has same-day T+0 settlement to BCP, an official zero-dependency Node SDK, a clean Yape token API, real webhooks, and S/0 monthly cost) and Mercado Pago as the FALLBACK (strong checkout, native Yape, and a confirmed nonprofit program "Mercado Libre Solidario" at 3.20% plus IGV). The single biggest design decision is to never sell a bare S/5 ticket through a card or voucher rail. Bundle to a sensible minimum (S/10 floor, or steer S/5 buyers to Yape where the economics are far better) so the fixed fee does not eat 70 percent of a S/5 entry. Two items must be resolved before any build: the pricing tiers (Rodrigo gave two contradictory framings) and the legal authorization, because Peru regulates charity raffles under Decreto Supremo N° 010-2016-IN and only certain entity types may run a "rifa con fines sociales."

## Body
## Scope and method

I verified current 2026 provider data via WebSearch and WebFetch (Culqi pricing page, Culqi developer docs, Mercado Pago developer docs, the Mercado Libre Solidario nonprofit program page, and three independent 2026 Peru payment-gateway comparison guides). Where a provider does not publish a number (PagoEfectivo standalone pricing, charity-specific Culqi rates), I say so and mark it for verification. All money is in soles, written S/.

The defining economic fact for this project: ticket sizes of S/5 to roughly S/30 are micro-payments. At these sizes the percentage fee is almost irrelevant. The fixed component (a per-transaction flat fee, or worse, a fixed minimum commission) is what determines whether the raffle is viable. This single fact drives the entire recommendation.

## The fixed-fee problem, made concrete

Culqi (and PagoEfectivo via Culqi) apply a minimum fixed commission of S/3.50 plus IGV on online payments under S/87.72. IGV is 18 percent, so that is about S/4.13 all-in.

What that does to each ticket framing:

| Ticket | Rail | Fee charged | Net to Teleton | Fee drag |
|---|---|---|---|---|
| S/5 single | Culqi card (min fee applies) | ~S/4.13 (S/3.50 + IGV) | ~S/0.87 | ~83% |
| S/5 single | Yape via Culqi (min fee applies) | ~S/4.13 | ~S/0.87 | ~83% |
| S/5 single | Yape Empresa direct (2.95%, no min) | ~S/0.15 | ~S/4.85 | ~3% |
| S/10 single | Culqi card (min fee applies) | ~S/4.13 | ~S/5.87 | ~41% |
| S/15 bundle | Culqi card (min fee applies) | ~S/4.13 | ~S/10.87 | ~28% |
| S/20 bundle | Culqi card (3.44% + ~S/0.74 USD-fixed + IGV) | ~S/1.65 | ~S/18.35 | ~8% |
| S/30 bundle | Culqi card | ~S/2.15 | ~S/27.85 | ~7% |

(The S/0.20 USD online fixed fee converts to roughly S/0.74 at current rates and is itself subject to IGV; treat it as roughly S/0.87 all-in. On tickets under S/87.72 it is absorbed into the S/3.50 minimum, so the minimum dominates.)

Read the table once and the design writes itself. A bare S/5 card sale loses 83 percent to fees. The same S/5 over Yape Empresa loses 3 percent. And every bundle above roughly S/12 to S/15 escapes the minimum-fee cliff and lands in single-digit fee drag. This is why the pricing model and the rail routing are not separate questions.

## Provider-by-provider comparison

### Culqi: RECOMMENDED PRIMARY

- Card support: Visa, Mastercard, Amex, Diners. National 3.44% + IGV, international 3.99% + IGV.
- Yape and wallets: Native. Yape at 3.44% + IGV via a documented token flow. Also supports PagoEfectivo and BCP Cuotealo.
- Fees on small tickets: The S/3.50 + IGV minimum on sub-S/87.72 payments is the central constraint. Plus a S/0.20 USD online fixed fee.
- Settlement: T+0, same day, with a BCP account for sales before 4 p.m. (funds 6 to 8 p.m.), including weekends and holidays. T+2 for payment-link sales. This is the strongest settlement story for a cash-tight charity.
- Webhooks: Yes. Configurable in CulqiPanel under Eventos. Event categories cover Tokens, Cargos (charges), Devoluciones (refunds), Clientes, Tarjetas, Planes, Suscripciones, Ordenes. Idempotency is handled by deduplicating on the event id.
- Node SDK: Yes. Official-org-adjacent `culqi-node` on npm, TypeScript, zero runtime dependencies. Plus community React/Next.js wrappers (react-culqi-next, culqi-react-nextjs-integration). The frontend uses `js.culqi.com/checkout-js`; the token is processed server-to-server.
- PCI scope: Using Culqi Checkout (hosted popup, tokenized) keeps you at the lightest SAQ level. Using the raw Culqi API for card data triggers PCI DSS SAQ-D. Use Checkout, not raw API.
- Sandbox: Yes, test keys (test vs live) are documented.
- Onboarding: Zero setup and no monthly fee for digital products. Requires a Peruvian RUC and a bank account (BCP for same-day settlement).

Why primary: it is the only option that combines Peru-native rails, native Yape, same-day BCP settlement, real webhooks, a real Node SDK, and S/0 fixed monthly cost. For a mobile-first Next.js raffle, this is the cleanest fit.

### Mercado Pago: RECOMMENDED FALLBACK

- Card support: Full card suite plus bank transfer and cash.
- Yape and wallets: Native Yape via Checkout API (phone + OTP token flow).
- Fees: 3.49% + S/1 + IGV (instant settlement) or 3.29% + S/1 + IGV (14-day). The fixed component is S/1, lower and flatter than Culqi's S/3.50 minimum, which makes Mercado Pago less punishing on the smallest tickets even though its percentage is similar. No fixed monthly cost.
- Nonprofit program: Mercado Libre Solidario gives a bonified donation rate of 3.20% + IGV. See the eligibility caveat below; it likely excludes Teleton on the income ceiling, but it is worth a direct check.
- Settlement: User-selectable instant or 14 days, free unlimited withdrawals to any bank.
- Webhooks: Yes (IPN / Webhooks), mature documentation.
- Node SDK: Yes, official `mercadopago` npm SDK, well maintained, strong Next.js community usage.
- PCI scope: Checkout Pro / Bricks keep PCI scope minimal.
- Sandbox: Yes, robust test-user tooling.
- Onboarding: Self-serve, fast, no monthly fee. Largest brand-recognition among the 22 to 38 audience.

Why fallback and not primary: settlement to a BCP account is not same-day the way Culqi is, and the local Yape integration plus same-day cash matters more for a Peru charity than Mercado Pago's regional polish. But it is the natural second rail and a clean redundancy if Culqi onboarding stalls.

### Izipay: strong alternative, hold in reserve

- Card support: National 3.44% + IGV, international 3.95 to 4.09% + IGV. New-merchant promo as low as 1.99%.
- Yape/wallets: Yes, plus QR.
- Settlement: T+0 to an Interbank account, T+1 to other banks. (Note: best same-day economics assume Interbank; Culqi assumes BCP. Match the rail to Teleton's actual bank.)
- Webhooks/API: REST API exists and has modernized, but developer documentation and Node tooling are thinner than Culqi or Mercado Pago. No first-class Node SDK found.
- Onboarding: BCP-group / Niubiz-affiliated; zero monthly fees for online.
- Verdict: credible, especially if Teleton banks with Interbank or already has an Izipay relationship. Demote below Culqi only on developer-experience and Node-SDK maturity. Worth naming to Rodrigo as the third option.

### Niubiz: not recommended for this use case

- Fees: e-commerce 3.45% + USD 0.15 + IGV, link 3.99% + IGV, plus a monthly maintenance fee around S/50 + IGV and an affiliation fee around S/300.
- Settlement: T+1 to T+3 (T+3 for e-commerce), the slowest here.
- Verdict: monthly fee plus slow settlement plus heavier enterprise integration make it wrong for a short-lived, cash-tight micro-raffle. It is built for established high-volume merchants.

### PagoEfectivo: include as a secondary method, not the backbone

- What it is: cash and bank-transfer voucher. Generates a unique CIP code the buyer pays at 70,000+ agents, banks, or wallets. Reaches the unbanked.
- Fees: not publicly disclosed standalone; via Culqi it appears as 3.99% (S/3.50 minimum), so the same micro-ticket cliff applies.
- Settlement/webhooks: asynchronous. The order stays Pending until PagoEfectivo confirms, then a webhook fires. This is a reconciliation pattern, not an instant one.
- Verdict: offer it as an additional method inside Culqi for buyers without cards or Yape, but do not center the flow on it. The async confirmation and the S/3.50 minimum both fight the micro-raffle model. Best paired only with bundles.

### Yape: must-have method, accessed through a gateway

- Reach: Peru's dominant wallet. The 22 to 38 audience expects it. For S/5 tickets it is the only rail with acceptable economics.
- Direct (Yape Empresa): 2.95% on daily sales, no fixed minimum, real-time to BCP, zero monthly fee. But there is no direct public API. You integrate Yape through Culqi, Izipay, Mercado Pago, PayU, or Alignet.
- Limits: payer max S/2,000/day; Yape Empresa per-transaction caps configurable (S/500 default tier). Not a constraint for S/5 to S/30 tickets.
- Recommendation: expose Yape inside Culqi as a first-class, prominent payment button. It will likely be the highest-volume method in a social-media push.

### PLIN: defer, do not block on it

- Reach: second wallet, bank-consortium backed (BBVA, Interbank, Scotiabank).
- Integration: no usable public e-commerce API today. Native checkout integration is still maturing (ProntoPaga has announced PLIN integration targeted for Q2 2026, unverified for production readiness).
- Verdict: do not gate the build on PLIN. If a gateway exposes it by launch, add it; otherwise launch with Yape and revisit. Avoid the manual "upload your transfer receipt" pattern. For a charity handling real money and public trust, manual reconciliation is an audit and fraud liability.

## Provider summary table

| Provider | Card | Yape | Fixed fee on small ticket | Settlement | Webhooks | Node SDK | PCI scope | Sandbox | Monthly cost |
|---|---|---|---|---|---|---|---|---|---|
| Culqi (primary) | 3.44% + IGV | 3.44% + IGV | S/3.50 min under S/87.72 | T+0 BCP same day | Yes | Yes (culqi-node) | SAQ-A with Checkout | Yes | S/0 |
| Mercado Pago (fallback) | 3.49% + S/1 + IGV | Yes (Checkout API) | S/1 flat | Instant or 14d | Yes | Yes (mercadopago) | Low (Bricks) | Yes | S/0 |
| Izipay | 3.44% + IGV | Yes + QR | Not clearly published | T+0 Interbank / T+1 | Yes (thinner) | No first-class | Varies | Yes | S/0 online |
| Niubiz | 3.45% + USD 0.15 + IGV | Yes | USD 0.15 + monthly | T+1 to T+3 | Yes | No | Heavier | Yes | ~S/50 + IGV |
| PagoEfectivo | n/a (voucher) | via wallets | S/3.50 via Culqi | Async on confirm | Yes (via gateway) | via gateway | n/a | via gateway | via gateway |
| Yape Empresa | n/a | 2.95%, no min | None | Real-time BCP | via gateway | via gateway | n/a | via gateway | S/0 |
| PLIN | n/a | n/a | 0% (P2P) | Real-time | No public API | No | n/a | No | S/0 |

## Minimizing fee drag on S/5 tickets

This is the core engineering and product question. Four levers, in priority order:

1. Set a sensible minimum and bundle by default. Do not sell a bare S/5 ticket through a card or voucher rail. Make the smallest card/voucher purchase land at S/10 or above, ideally the upsell bundle (for example S/15 for three chances), which clears the S/3.50 minimum-fee cliff and brings drag under 30 percent. This is exactly what Rodrigo's upsell flow already wants to do. Lean into it. The pre-payment upsell is not just a revenue lever, it is the fee-survival mechanism.
2. Route S/5 to Yape, not cards. If a true S/5 single entry must exist (for the viral low-barrier hook), steer it to Yape, where the economics are roughly 3 percent rather than 83 percent. Present Yape as the default, most-prominent method on mobile.
3. Frame fees as donor-absorbed, with a transparent option. For a charity, the cleanest pattern is a small "cubre la comision" toggle on the payment step ("Suma S/1 para cubrir la comision y que el 100 por ciento de tu aporte llegue a Teleton"). Many donors opt in. This protects net proceeds without hiding anything, which matters for a national charity's reputation. Make it opt-in and honest, never a dark pattern.
4. Negotiate the rate. Culqi, Izipay, and Niubiz all state rates are volume- and negotiation-dependent. During a September push, volume will be real. Have Rodrigo or Teleton's finance team request a charity or campaign rate in writing before launch, and ask specifically whether the S/3.50 minimum can be waived or lowered for a registered nonprofit. Flag this as a verify item.

The recommended default product: a S/10 entry as the floor, the upsell ladder built on top, and Yape positioned as the primary rail for price-sensitive buyers. This keeps blended fee drag in the single-to-low-double digits rather than the catastrophic 83 percent a bare S/5 card sale implies.

## Idempotency and webhook reconciliation

Real money plus retried mobile requests plus social-media traffic spikes make idempotency non-negotiable.

- Generate a server-side idempotency key per checkout attempt (a UUID stored against the buyer's pending order before you ever call the provider). Persist it. If the same key is retried, return the existing result rather than creating a second charge.
- Treat the webhook as the source of truth for payment state, not the synchronous API response. The buyer's email confirmation and the "entry recorded in the database" step must be driven by the webhook (charge confirmed), not by the browser returning from the popup. Mobile users close tabs.
- Deduplicate webhooks on the provider event id. Culqi explicitly identifies events by a unique id; store processed ids and ignore repeats. Mercado Pago sends repeated IPN notifications by design, so the same rule applies.
- Verify webhook authenticity. Confirm the signature mechanism for whichever provider is live (Culqi via CulqiPanel-configured endpoint; Mercado Pago via its signature header) and reject unsigned or mismatched payloads. Require HTTPS on the webhook route (trivial in a Next.js Route Handler on Vercel).
- Reconcile asynchronously. For PagoEfectivo specifically, orders sit Pending until the buyer pays at an agent. Model an explicit Pending state with a timeout, and reconcile against the provider's charge status as the backstop if a webhook is missed. A nightly reconciliation job comparing your DB to the provider's charge list closes the gap and gives auditors a clean trail.
- One charge, one entry, one ledger row. Make the database write that creates raffle entries idempotent on the charge id so a double-fired webhook never mints duplicate chances. This directly protects draw fairness.

## Refunds

- Both Culqi and Mercado Pago expose programmatic refunds. Culqi has a Devoluciones object and refund webhook events; `culqi-node` documents creating refunds. Mercado Pago supports full and partial refunds via SDK.
- Policy decision needed from Teleton: are raffle entries refundable at all? For a charity raffle the defensible stance is generally no refunds except for duplicate charges or proven error, stated clearly at purchase. Put the policy in the terms the buyer accepts on the registration step.
- Always support a duplicate-charge refund path operationally, even if entries are otherwise non-refundable. Idempotency should prevent duplicates, but the refund capability is the safety net and a reputation protector.
- Refunds must reverse the raffle entry. A refunded charge has to void the associated chances in the database before the draw filter runs, or you compromise fairness. Wire this into the refund webhook handler.

## Chargeback and fraud basics

- Chargebacks apply to the card rails. Yape, PLIN, and PagoEfectivo are push payments and are effectively non-reversible by the buyer, which is one more reason to favor Yape for this audience. Card chargebacks are the real exposure.
- Use hosted Checkout (Culqi Checkout / Mercado Pago Bricks). It carries the issuer fraud tooling and keeps PCI scope at the lightest level. Do not handle raw card PANs.
- Expect 3DS / OTP step-up on cards; both providers support it. Keep it on for fraud protection even though it adds a step.
- Rate-limit and bot-protect the registration and payment endpoints. A viral social push is exactly when carding attacks (testing stolen cards on a cheap S/5 charge) appear. Add a lightweight challenge (hCaptcha or Turnstile) on the registration step and velocity limits per phone, email, and IP.
- Keep an immutable audit log. Every charge, webhook, refund, and entry-creation event should be append-only and timestamped. For a national charity running a public raffle, auditability is not optional. It protects Teleton if the draw or the fund use is ever questioned.

## Nonprofit angle (verify)

Teleton being a registered charity may reduce fees, but the one concrete program I found likely does not fit on its own terms:

- Mercado Libre Solidario / Mercado Pago: bonified donation rate of 3.20% + IGV. Eligibility requires a Peruvian nonprofit registered in Registros Publicos and SUNAT, and, per the current published rule, annual income not exceeding the local equivalent of USD 500,000. Teleton Peru's scale very likely exceeds USD 500,000 per year, which would disqualify it from this specific program. Verify directly with sustentabilidad@mercadolibre.com; the ceiling may have exceptions for recognized national charities, and there may be a separate enterprise-donation arrangement.
- Culqi, Izipay, Niubiz: no published charity rate, but all three negotiate by volume and case. Teleton's brand and campaign volume are strong negotiating leverage. Ask each, in writing, for a campaign or nonprofit rate and explicitly for relief on the S/3.50 minimum.

## Legal flag (resolve before build, not a payment item but it gates the project)

This is outside the strict payment-stack remit but it is load-bearing and I surfaced it during research. Peru regulates "rifas con fines sociales" under Decreto Supremo N° 010-2016-IN (Reglamento de Promociones Comerciales, Rifas con Fines Sociales y Colectas Publicas), and lottery-type games sit under state oversight. Authorization to run a charity raffle is typically required, with the organizing entity, its RUC and legal representative, the social purpose, and a post-event financial report submitted to the relevant authority. Confirm whether Teleton needs an authorization for both the August warm-up and the September 12 main raffle, and whether the prize structure and ticket model fit the "rifa con fines sociales" definition versus a regulated lottery. This must be cleared by Teleton's legal team. The payment integration is straightforward; the regulatory clearance is the real long-pole risk. (Marked [inferred] that authorization applies to this specific model; the legal team must confirm.)

## Recommended build shape (Next.js)

- Frontend: Culqi Checkout via `js.culqi.com/checkout-js` for cards and Yape, with Yape positioned as the primary mobile method. Optional PagoEfectivo as a secondary method for the unbanked.
- Backend: Next.js Route Handlers. `culqi-node` for server-side charge creation and refunds. A webhook Route Handler as the source of truth, signature-verified, idempotent on event id.
- Data: a charge-keyed entries table, append-only audit log, explicit Pending state for async methods, nightly reconciliation job.
- Fallback: keep the provider behind a thin internal interface so swapping in Mercado Pago (`mercadopago` SDK) is a config-and-adapter change, not a rewrite. This is the redundancy that matters if Culqi onboarding or uptime ever fails mid-campaign.

## Recommendations
- **Use Culqi as the PRIMARY payment provider via Culqi Checkout (hosted, tokenized) with the official culqi-node SDK on the Next.js backend.**: Peru-native, BCP-backed same-day T+0 settlement, native Yape, real webhooks, zero-dependency Node SDK, S/0 monthly cost, and lightest PCI scope (SAQ-A) when using hosted Checkout. Best overall fit for a cash-tight mobile-first charity raffle.
- **Use Mercado Pago as the FALLBACK, integrated behind a thin provider interface so it can be swapped in via config, not a rewrite.**: Mature checkout and webhooks, official mercadopago npm SDK, native Yape, a lower flat fixed fee (S/1 vs Culqi's S/3.50 minimum), and a confirmed nonprofit program. Provides real redundancy if Culqi onboarding stalls or fails mid-campaign.
- **Never sell a bare S/5 ticket through a card or voucher rail. Set a S/10 floor for card/voucher purchases and route true S/5 single entries to Yape.**: Culqi's S/3.50-plus-IGV minimum fee consumes ~83 percent of a S/5 card sale but only ~3 percent of the same S/5 over Yape Empresa (2.95%, no minimum). The fixed fee, not the percentage, is the real economics at micro-ticket sizes.
- **Lean into Rodrigo's pre-payment upsell as the fee-survival mechanism, building bundles at S/15 and above as the default purchase.**: Bundles above roughly S/12 to S/15 clear the minimum-fee cliff and drop fee drag below 30 percent, then into single digits at S/20 to S/30. The upsell is both a revenue lever and the thing that makes the unit economics work.
- **Add an honest opt-in 'cubre la comision' toggle on the payment step (for example 'Suma S/1 para que el 100 por ciento de tu aporte llegue a Teleton').**: Lets donors absorb the processing fee transparently, protecting net proceeds for the charity without any dark pattern. Appropriate for a national charity where reputation and trust are paramount.
- **Drive payment state, the confirmation email, and the database entry from the verified, idempotent webhook, not the browser response. Deduplicate on the provider event id and require HTTPS on the webhook route.**: Mobile users close tabs; retries and traffic spikes during social pushes will cause duplicate and dropped synchronous responses. The webhook is the only reliable source of truth, and idempotency on event id is what prevents duplicate raffle entries that would compromise draw fairness.
- **Expose Yape as the prominent default mobile method (via Culqi); offer PagoEfectivo only as a secondary method paired with bundles; defer PLIN until a gateway exposes a production API.**: Yape is dominant with the 22 to 38 audience and has the only acceptable economics on small tickets. PagoEfectivo's async confirmation and S/3.50 minimum fight the model. PLIN has no usable public e-commerce API today, so blocking on it would delay launch.
- **Have Teleton request a written charity/campaign rate from Culqi, Izipay, and Mercado Pago before launch, explicitly asking for relief on the S/3.50 minimum, and verify Mercado Libre Solidario eligibility with sustentabilidad@mercadolibre.com.**: All three providers negotiate by volume; Teleton's brand and September campaign volume are real leverage. Mercado Libre Solidario offers 3.20% + IGV but its published USD 500,000 annual-income ceiling likely disqualifies Teleton, so confirm whether a national-charity exception exists.
- **Implement append-only audit logging, an explicit Pending state with a nightly reconciliation job, refund handling that voids the associated raffle entries, and bot/rate-limiting (Turnstile or hCaptcha) plus 3DS on card payments.**: Real money plus a national charity's reputation demand auditability and fraud resistance. Reconciliation closes missed-webhook gaps, refund-driven entry voiding protects fairness, and rate-limiting blocks the carding attacks that target cheap charges during viral pushes.

## Open Questions
- Pricing tiers must be resolved: Rodrigo gave two contradictory framings (S/10 base + S/5 + S/5 versus S/5 base + S/5/S/10/S/15 upsell). The build cannot proceed without a single canonical ladder. Recommend a S/10 floor for card/voucher and Yape-only for any S/5 entry.
- Returning-buyer model: confirm whether to build phone/email recognition of prior buyers (showing existing entries and remaining upsell options) or fall back to the simpler flat-priced repeat-purchase model. This materially changes data model and effort.
- Legal authorization: does Teleton need state authorization for a 'rifa con fines sociales' under Decreto Supremo N 010-2016-IN for both the August warm-up and the September 12 main raffle, and does the prize/ticket model fit that definition rather than a regulated lottery? Must be cleared by Teleton legal before build.
- Which bank does Teleton settle to? Culqi's same-day T+0 assumes a BCP account; Izipay's T+0 assumes Interbank. The primary-provider choice should match Teleton's actual banking relationship.
- Refund policy: are raffle entries refundable at all, or only for duplicate charges and proven errors? This needs a stated policy in the purchase terms before launch.
- Does Teleton want to absorb processing fees, pass them to donors via an opt-in toggle, or net them out of proceeds? This affects both the checkout UX and the fundraising math.
- Confirm exact Culqi and Mercado Pago webhook signature-verification mechanisms against live developer docs at build time, since the public doc excerpts did not fully specify the signing scheme.

## Risks
- [high] A bare S/5 ticket sold through a card or PagoEfectivo rail loses roughly 83 percent to the S/3.50 + IGV minimum fee, making the headline price economically pointless and potentially embarrassing for the charity if exposed.  -> FIX: Set a S/10 card/voucher floor, route all S/5 single entries to Yape (2.95%, no minimum), and make bundles (S/15+) the default via the upsell. Add an opt-in donor-covers-fee toggle.
- [high] Driving raffle entries off the synchronous browser response instead of the webhook causes lost or duplicate entries during traffic spikes and on mobile (tab closes, retries), directly compromising draw fairness and donor trust.  -> FIX: Make the webhook the source of truth, verify its signature, deduplicate on provider event id, and make the entry-creation DB write idempotent on charge id. Add a nightly reconciliation job.
- [high] Peru regulates charity raffles under Decreto Supremo N 010-2016-IN; running an unauthorized 'rifa con fines sociales' could expose a national charity to legal and reputational damage. This is the project's long-pole risk, independent of the payment stack.  -> FIX: Teleton legal must confirm authorization requirements and whether the ticket/prize model qualifies as a social-purpose raffle versus a regulated lottery, for both the August and September events, before build.
- [medium] Carding and fraud attacks spike precisely during viral social pushes, where attackers test stolen cards against cheap S/5 charges, generating chargebacks and fees against the charity.  -> FIX: Use hosted Checkout with issuer fraud tooling, keep 3DS/OTP on, add Turnstile/hCaptcha on registration, and apply velocity limits per phone, email, and IP. Favor push rails (Yape) which are non-chargeback-able.
- [medium] Mercado Libre Solidario's nonprofit rate (3.20% + IGV) likely excludes Teleton due to the published USD 500,000 annual-income ceiling, so the assumed charity discount may not materialize on the fallback provider.  -> FIX: Verify eligibility and any national-charity exception directly with sustentabilidad@mercadolibre.com; in parallel, negotiate written campaign/charity rates with Culqi and Izipay and request relief on the S/3.50 minimum.
- [medium] Building the returning-buyer recognition flow (by phone/email, showing prior entries) introduces personal-data storage, identity-matching, and security obligations that expand scope and PII liability for a charity handling real donor data.  -> FIX: Decide explicitly whether to build it or use the flat-priced repeat-purchase fallback. If built, minimize stored PII, encrypt contact data, and document a clear privacy/data-handling stance in the purchase terms.
- [medium] Single-provider dependency: if Culqi onboarding stalls (RUC, bank, evaluation) or the provider has an outage during the September 12 main event, the campaign has no payment path at its highest-traffic moment.  -> FIX: Build behind a thin provider-adapter interface so Mercado Pago (mercadopago SDK) can be swapped in via config. Complete Mercado Pago onboarding in parallel as a hot standby before launch.
- [low] PLIN has no production-ready public e-commerce API in 2026 (ProntoPaga integration only announced for Q2 2026, unverified). Blocking the build on PLIN, or relying on manual receipt-upload reconciliation, would delay launch and create an audit/fraud hole.  -> FIX: Launch with Yape as the primary wallet and add PLIN only if a gateway exposes a verified production API by launch. Never use manual receipt-upload reconciliation for a charity handling real money.

## Sources
- https://culqi.com/precios/
- https://culqi.com/productos/online-pasarela-de-pagos/
- https://culqi.com/
- https://docs.culqi.com/es/documentacion/pagos-online/webhooks/
- https://docs.culqi.com/es/documentacion/pagos-online/cargo-unico/tokens-yape
- https://apidocs.culqi.com/
- https://github.com/giwiro/culqi-node
- https://www.npmjs.com/package/culqi-node
- https://github.com/culqi
- https://github.com/moiseshp/culqi-react-nextjs-integration
- https://github.com/hebertdev/react-culqi-next
- https://www.mercadopago.com.pe/herramientas-para-vender/check-out
- https://www.mercadopago.com.pe/developers/es/docs/checkout-api-payments/integration-configuration/yape
- https://www.mercadopago.com.pe/developers/es/news/2024/07/19/Integrate-Yape-into-Checkout-API-with-the-support-of-the-new-documentation
- https://www.mercadolibre.com.pe/institucional/cuidamos/mercado-libre-solidario
- https://sustentabilidadmercadolibre.com/en/iniciativas/mercado-libre-solidario
- https://sumafraternidad.org/mercado-libre-solidario-el-programa-de-mercadolibre-para-ong/
- https://www.izipay.pe/izipay-online/
- https://www.izipay.pe/
- https://www.niubiz.com.pe/soluciones/pago-web
- https://adratechsystems.com/recursos/niubiz-peru-guia-completa-costos-integracion
- https://www.yape.com.pe/productos/yape-empresa
- https://www.yape.com.pe/preguntas-frecuentes/yape-empresa/yape-empresa-tiene-algun-costo
- https://docs.ebanx.com/docs/payments/guides/accept-payments/api/peru/pago-efectivo/
- https://www.nuvei.com/apm/pagoefecivo
- https://kom.pe/integracion-de-yape-y-plin-metodos-de-pago-locales-para-tiendas-virtuales-en-lima/
- https://gestion.pe/economia/empresas/prontopaga-integrara-plin-a-su-plataforma-en-2026-y-proyecta-duplicar-pagos-en-peru-noticia/
- https://adratechsystems.com/recursos/guia-completa-pasarelas-pago-peru-2026
- https://devsprinters.site/blog/comparativa-pasarelas-pago-peru-2026
- https://alaz.pe/blog/pasarela-de-pago-peru-como-elegir-culqi-stripe-izipay-niubiz
- https://www.gob.pe/25672-solicitar-autorizacion-para-realizar-rifas-sorteos-bingos-loterias-y-similares
- https://busquedas.elperuano.pe/normaslegales/aprueban-reglamento-de-promociones-comerciales-rifas-con-fi-decreto-supremo-n-010-2016-in-1409577-9