Copec app icon

Copec Pay · Chilean fuel wallet

Copec Pay: the wallet ledger, Full points and fuel records behind one login

Copec Pay sits in a short list: it is one of eight non-bank funds-provision accounts (CPF) cleared to issue a prepaid card to the Chilean public, alongside Mercado Pago, Tenpo, Prex, Global66, Tapp, La Polar and Prepago Los Héroes, per the prepaid-account guides that track the CMF register. That status is the whole reason an integrator cares. Behind a single login the app carries a real money ledger, a points economy, and a stream of fuel purchases — three different record types most apps would split across three vendors.

Copec calls the money side Copec Pay and the loyalty side Full. The work here is to reach both as structured records under the account holder's authorization, normalize them, and hand back something a backend can query on a schedule. The rest of this page is what that build looks like for this specific app.

What Copec keeps behind the login

Each row below is a surface the app exposes to a signed-in user, mapped to what an integrator would actually do with it. Granularity is what we expect from the screens and the published behavior, confirmed against live responses during a build.

Data domainWhere it lives in the appGranularityIntegration use
Wallet balanceCopec Pay account homeCurrent available funds, in CLPReal-time balance checks before a charge or payout decision
Money loadsCopec Pay load historyPer-event: amount, source, timestampReconcile top-ups against an external funding source
TransfersCopec Pay transfersContact transfers (free, instant) and outbound bank transfersCash-flow tracking; the app describes a 5,000,000-CLP daily ceiling on bank transfers
Fuel purchasesScan & Pay at stationsPer-transaction: litres or amount, station, timeSpend analytics, expense feeds, fleet-style reporting
Store purchasesPronto, Punto, order-aheadPer-line purchase rowsItemized spend, receipt sync
Full pointsFull catalog and missionsPoints earned, redeemed, coupon and mission stateLoyalty reconciliation, reward automation
bip! top-upsbip card rechargeRecharge amount and timeTransit-spend records; thinner than the wallet rows

A token-and-balance call, sketched

Illustrative, not copied from production. The shape — an authenticated session, then a read against the account and the points ledger — is what the protocol analysis pins down precisely during the build, including the exact auth method and refresh behavior.

# 1. Establish a session under the account holder's consent.
#    Auth method (token vs. cookie chain) is confirmed during analysis.
POST /pay/v1/session
  { "device_id": "...", "credential": "<consented>" }
-> 200 { "access_token": "...", "expires_in": 900, "refresh_token": "..." }

# 2. Read the wallet account.
GET /pay/v1/account/balance
  Authorization: Bearer <access_token>
-> 200 { "currency": "CLP", "available": 48230, "account_id": "cpf_..." }

# 3. Pull recent movements (loads, transfers, purchases).
GET /pay/v1/account/movements?since=2026-05-01
-> 200 { "items": [
     { "type": "load",      "amount": 20000, "ts": "2026-05-30T11:04:00-04:00" },
     { "type": "transfer",  "amount": -5000, "to": "contact", "ts": "..." },
     { "type": "fuel",      "amount": -18900, "station": "...", "ts": "..." }
   ], "next_cursor": "..." }

# 4. Read the Full loyalty ledger as a separate account.
GET /loyalty/v1/full/points
-> 200 { "balance_points": 3120, "earned_ytd": 5400, "pending": [ ... ] }

# Error handling we wire in: 401 -> refresh; 429 -> backoff;
# schema drift on the movements feed -> flag, do not silently drop rows.
      

What you receive

Deliverables are tied to the two account types above, not a generic checklist.

  • An OpenAPI/Swagger specification covering the session, balance, movements and Full-points reads as we model them for Copec Pay.
  • A protocol and auth-flow report: how the session is established and refreshed, token versus cookie handling, and the request signing the app uses.
  • Runnable source for the core reads in Python and Node.js — balance, paginated movements, and the points ledger — with the pagination and retry logic already in place.
  • Automated tests against recorded fixtures, including the 401-refresh path and the movements schema-drift flag.
  • Interface documentation an in-house team can maintain: field meanings, the CLP money model, and how fuel rows differ from store rows.
  • Compliance and retention guidance for holding Chilean financial data under consent — what to log, what to minimize, how long to keep it.

Normalizing wallet and points into one model

Copec's two ledgers reconcile against each other — a fuel load both moves pesos and earns Full points. We normalize them so a single sync can line up the money event with the points it generated.

// Unified movement (money side)
{ "account": "copec_pay", "kind": "fuel_purchase",
  "amount_minor": -18900, "currency": "CLP",
  "merchant": { "type": "station", "name": "..." },
  "occurred_at": "2026-05-30T18:22:00Z",
  "links": { "loyalty_event": "full_evt_91x" } }

// Loyalty event (points side), linked back
{ "account": "full", "kind": "earn",
  "points": 47, "source": "fuel_load",
  "occurred_at": "2026-05-30T18:22:00Z",
  "links": { "movement": "mv_4471" } }
      

Routes to the Copec Pay ledger

Three approaches genuinely apply to this app. They are not equal, and the right pick depends on how soon Chile's open-finance channel actually carries CPF data.

Authorized interface integration (protocol analysis)

Reading the app's own traffic under the account holder's authorization reaches everything a user sees today: balance, movements, transfers, fuel and store purchases, and the Full ledger. Effort is moderate and front-loaded into mapping the session and the movements feed. Durability depends on the app's front end staying put; we account for that with a re-validation step, described below. This is the route that works right now, end to end, and it is what we would lead with for Copec.

Regulated Open Finance consent (Ley Fintech 21,521)

As the CMF's Open Finance System phases in from July 2026, Copec Pay — a CPF and card issuer — falls among the institutions the regime can oblige to share consented data through standardized APIs. When that channel carries Copec's account data, it becomes the most durable read because it is consent-native and versioned by the regulator. We design the integration so it can move onto this channel as it becomes available, rather than rebuilding from scratch.

User-consented credential access

Where a customer holds the account-holder relationship directly, a consented credential flow keeps the read scoped to that user. It pairs naturally with the protocol route and is how we keep individual consent records clean and revocable.

For most teams asking us about Copec today, the protocol route carries the project while the Fintech-Act channel is built in as the upgrade path it grows into. We would say so plainly in the scoping call and design the sync so the switch is a configuration change, not a second engagement.

Chile passed the Fintech Act (Law 21,521) in January 2023, and the CMF issued NCG 514 in July 2024 to govern the Open Finance System. The regime names banks, payment-card issuers and funds-provision-account operators as obligated participants once it is live, with a gradual rollout beginning July 2026 and a first phase running on a 24-month horizon, per the CMF and open-finance trackers. Copec Pay sits inside that perimeter as a CPF and card issuer.

Because the System is still phasing in, the dependable basis for a build today is the account holder's own authorization — explicit consent, scoped to the records actually needed, with an expiry and a revocation path the user controls. We keep consent records and access logs, minimize stored fields to what the integration uses, and work under an NDA where the engagement calls for one. That is how the studio operates regardless of which channel carries the data; the regulated route simply formalizes the same consent the protocol route already relies on.

What we plan around in a Copec build

Two things on this app need real handling, and we build for them up front.

  • Two ledgers that must reconcile. The money account and the Full points ledger are separate stores that describe the same events from different angles. We model them as linked accounts so a fuel load resolves to both a peso movement and a points entry, which keeps the sync honest when one side updates a beat before the other.
  • A consumer front end that changes. Copec ships frequent app updates, so the session and movements surfaces can shift. We wire a small re-validation pass into the maintenance plan that checks the live shape against the spec and flags drift before it reaches your data, rather than letting rows go missing quietly.
  • Transfer semantics and limits. Outbound bank transfers behave differently from free contact transfers, and the app describes a daily ceiling on the former. We encode that distinction in the movement model so cash-flow reporting does not treat the two as interchangeable.

Access to a consenting account or a working environment is arranged with you during onboarding — it is part of the engagement, handled together, not something to line up before we will start.

Screens we worked from

Store screenshots used while mapping the surfaces above. Tap to enlarge.

Copec app screen 1 Copec app screen 2 Copec app screen 3 Copec app screen 4 Copec app screen 5 Copec app screen 6 Copec app screen 7 Copec app screen 8

Other Chilean wallets in the same integration picture

Teams that need Copec usually need its neighbors too, because Chilean spend is spread across several prepaid accounts. Each below holds per-user records a unified integration would line up the same way.

  • MACH — Bci's prepaid wallet; holds balance, transfers and card purchases for a large user base.
  • Tenpo — a non-bank prepaid Mastercard account linked to Credicorp, with its own movement and card-spend history.
  • Mercado Pago — Mercado Libre's wallet and the most-held prepaid account in Chile, carrying balance, transfers and marketplace payments.
  • Chek — Banco Ripley's wallet, focused on instant payments and transfers.
  • Global66 — a multi-currency account with cross-border transfer records.
  • Prex — a prepaid account and card with load and spend history.
  • Tapp — another CPF prepaid account on the CMF-tracked list, holding balance and movements.
  • Prepago Los Héroes — a funds-provision account tied to a welfare-fund membership, with its own ledger.

Questions integrators ask about Copec

Which Copec surfaces actually hold structured data worth syncing?

Three: the Copec Pay funds-provision account (balance, load events, contact and bank transfers), the Full points ledger with its catalog redemptions and missions, and the fuel-purchase history tied to Scan and Pay at stations, Pronto and Punto. The bip top-up records sit alongside but are thinner.

Copec Pay is a prepaid account, not a bank. Does Chile's Fintech Act still reach it?

Yes. Copec Pay operates as a non-bank funds-provision account (CPF) and a payment card issuer, which places it inside the institutions the CMF can pull into the Open Finance System under Law 21,521 and General Rule NCG 514. The phased rollout begins July 2026, so a build today rides the user's own consent and treats the regulated channel as the path it grows into.

Can transfers and Scan and Pay be read, or only the balance?

Read scope covers the balance plus the movement history that produces it: money loads, free instant transfers to contacts, and outbound bank transfers (the app describes a five-million-CLP daily ceiling on the latter). Scan and Pay shows up as station and store purchase rows. We map read first; any initiation of a payment is a separate, consented design with its own controls.

How do you handle the Full points side, which is loyalty rather than money?

The Full ledger is modeled as its own account: points earned per fuel load, coupon and catalog redemptions, mission completions and referral credits. We normalize it next to the wallet so a single sync can reconcile a peso movement against the points it generated.

Working together on Copec

A Copec engagement starts from two inputs: the app name and what you want out of its data. From there the typical cycle runs one to two weeks to a working, tested read of the wallet and Full ledgers. You can take it either way. The first is source-code delivery from $300 — you get the runnable source, the spec, the tests and the docs, and you pay after delivery once the integration satisfies you. The second is the pay-per-call hosted API, where we run the endpoints and you pay only for the calls you make, with no upfront fee. Either way the access and compliance pieces are arranged with you as we go. Tell us which Copec records you need and we will scope it — start at /contact.html.

How this was checked

Mapped on 2026-06-05 against the app's store description and Copec Pay's own product pages, cross-checked against the CMF's Open Finance materials and Chilean prepaid-account guides for the CPF status and the regulatory timeline. Primary sources opened for this brief:

Reviewed 2026-06-05 by the OpenBanking Studio integration desk.

App profile — Copec

Copec is the app of Copec, a Chilean fuel and convenience network. It combines fuel payment, a digital prepaid account (Copec Pay) and the Full loyalty program. Users scan a pump code to pay contactless, load and transfer money through the Copec Pay funds-provision account, send money to contacts or to other banks, accumulate and redeem Full points, recharge the bip! transit card, and opt into a carbon-footprint compensation program. Copec Pay also issues digital and physical prepaid cards usable beyond Copec's own stores. Package ID cl.copec.PagoClick; listed for Android and iOS. Details here are drawn from the app's public listing and Copec Pay's product pages.

Mapping reviewed 2026-06-05.

Copec app screen 1 enlarged
Copec app screen 2 enlarged
Copec app screen 3 enlarged
Copec app screen 4 enlarged
Copec app screen 5 enlarged
Copec app screen 6 enlarged
Copec app screen 7 enlarged
Copec app screen 8 enlarged