App Pago Facil API integration & OpenFinance services

1. Authorization & session bridge

We reverse-engineer the login handshake (DNI + SMS/email OTP and device binding) into an authorized OAuth-like flow. The resulting module issues and refreshes a session token, handles device-pinning challenges, and exposes a clean /auth/login and /auth/refresh interface for your backend — so you do not need to embed sensitive credentials inside business services.

2. Bill-payment statement endpoint

A paginated /v1/bills/history endpoint returns every utility, telco, cable, insurance or tax payment the user made through Pago Facil, with merchant ID, amount, currency (ARS), due date, barcode reference, status and the original digital receipt link. Used for reconciliation, bookkeeping automation, and audit trails.

3. Wallet balance & QR transactions

Query current ARS balance, pending holds, and a normalized transaction feed for QR-at-merchant payments. Each entry is mapped to an ISO 20022-inspired schema (txId, bookingDate, valueDate, merchantCategoryCode, counterparty) so it can drop into any OpenBanking aggregator.

4. Cash-in / cash-out & Western Union receipts

Physical deposits and withdrawals at Pago Facil branches are returned through /v1/cash/movements, including location code, operator, and receipt image URL. Incoming Western Union remittances are exposed through /v1/remittance/inbound with sender country, MTCN, FX rate and local ARS amount — crucial for gig-economy and cross-border payroll platforms.

5. Transfer rails (CBU / CVU / alias)

A lightweight transfer abstraction lets your backend trigger outbound transfers to any bank (CBU) or virtual wallet (CVU/alias) the same way a user would from the app. Idempotency keys, webhook callbacks and reversal handling are built in, so high-volume clients can integrate without rewriting state machines.

6. Notifications & webhooks

Instead of polling, you receive signed webhooks for every inbound event: bill paid, QR received, cash deposit confirmed, remittance arrived. Each webhook includes an HMAC signature, replay-safe nonce, and retry schedule — matching the reliability expectations of an OpenFinance production environment.

Scenario A — SME accounting auto-sync

Context: An SME in Córdoba accepts QR payments at three storefronts and pays suppliers through CBU transfers from its Pago Facil wallet.

Data / API: /v1/wallet/transactions for inbound QR, /v1/transfers/outbound for supplier payouts, and webhooks for same-day settlement updates.

OpenFinance mapping: Each transaction is normalized to the ISO 20022 camt.053 pattern and pushed into an accounting system (Tango, Bejerman, Contabilium, or cloud ERPs) so the merchant never re-types a line.

Scenario B — Cross-border payroll for remote workers

Context: A European payroll platform pays Argentine freelancers; workers receive funds via Western Union and withdraw cash or keep balance in the Pago Facil wallet.

Data / API: /v1/remittance/inbound provides MTCN, sender country, FX rate, and ARS amount; /v1/cash/movements confirms pickup.

OpenFinance mapping: Status events (CREATED → AVAILABLE → PAID) are published as OpenBanking-style payment-initiation responses so the payroll product can show "paid and received" to the worker.

Scenario C — Utility & tax reconciliation for a property manager

Context: A property management firm pays 400+ utility invoices per month on behalf of owners through Pago Facil.

Data / API: /v1/bills/history returns merchant code, service type (Edenor, Metrogas, AySA, ABL, Rentas provinciales), amount and receipt URL; webhook fires on BILL_PAID.

OpenFinance mapping: The feed feeds a per-property ledger in the firm's SaaS, and receipts are attached automatically to the owner statement PDF.

Scenario D — Risk & anti-fraud for a lender

Context: A consumer lender wants a cash-flow-based underwriting signal for thin-file borrowers who primarily use cash wallets.

Data / API: With user consent, /v1/wallet/transactions + /v1/bills/history returns 12 months of inflows/outflows; values are aggregated client-side to build Account Information Service (AIS)–like features.

OpenFinance mapping: Consent is time-bound, purpose-tagged, and revocable, matching PSD2 AIS patterns even though Argentina's framework is market-driven rather than mandated.

Scenario E — Unified dashboard across Argentine wallets

Context: A personal-finance SaaS aggregates multiple Argentine wallets (Mercado Pago, Ualá, Brubank, Naranja X, Cuenta DNI, MODO) and wants Pago Facil as an additional source.

Data / API: Our adapter exposes the same OpenFinance schema as the other wallet adapters the SaaS already uses, so only a new connector has to be wired in.

OpenFinance mapping: Transactions are deduplicated against CBU/CVU movements on the bank side to avoid double-counting remittances received through Western Union.

Technical implementation — login & session refresh

POST /api/v1/pagofacil/auth/login
Content-Type: application/json

{
  "dni": "30123456",
  "password": "<ENCRYPTED>",
  "device_id": "b7a8…",
  "otp": "442109"
}

200 OK
{
  "access_token": "eyJhbGciOi...",
  "refresh_token": "rt_8f…",
  "expires_in": 1800,
  "account": {
    "cvu": "0000003100099999999999",
    "alias": "pagofacil.jdoe",
    "kyc_level": 2
  }
}

Login mirrors the in-app DNI + OTP + device-binding flow. Failed attempts surface domain errors (INVALID_OTP, DEVICE_LOCKED, KYC_REQUIRED) so your UI can drive recovery without parsing HTML.

Technical implementation — bill-payment statement

POST /api/v1/pagofacil/bills/history
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "from_date": "2025-01-01",
  "to_date":   "2025-03-31",
  "page": 1,
  "page_size": 50,
  "category": ["utilities","telco","tax"]
}

200 OK
{
  "page": 1,
  "total": 137,
  "items": [
    {
      "bill_id":"bf_01HXYZ…",
      "merchant":"Edenor",
      "merchant_code":"EDN",
      "category":"utilities",
      "amount": 23485.12,
      "currency":"ARS",
      "paid_at":"2025-03-12T14:05:22-03:00",
      "barcode":"8001 0001 2345 6789 …",
      "receipt_url":"https://rcp.pagofacil/rcp/bf_01HXYZ.pdf",
      "status":"PAID"
    }
  ]
}

Technical implementation — webhook for remittance

POST https://your-backend.example/pagofacil/webhook
X-PagoFacil-Signature: t=1711990000,v1=5f3c…
Content-Type: application/json

{
  "event":"REMITTANCE_AVAILABLE",
  "event_id":"evt_01HXY…",
  "occurred_at":"2025-04-02T10:14:03Z",
  "data":{
    "mtcn":"1234567890",
    "sender_country":"ES",
    "fx_rate":1180.55,
    "amount_original":{"value":250,"currency":"EUR"},
    "amount_local":{"value":295137.50,"currency":"ARS"},
    "pickup_method":"WALLET"
  }
}

# HMAC verification (pseudocode)
expected = hmac_sha256(secret, f"{t}.{body}")
assert constant_time_eq(expected, v1)

Every webhook is signed, replay-protected via timestamp and nonce, and retried with exponential back-off up to 24 hours. This matches production-grade expectations for OpenFinance event buses.

Compliance & privacy

App Pago Facil is operated inside Argentina's Payment Service Provider (PSPCP) perimeter supervised by the Banco Central de la República Argentina (BCRA). Recent BCRA communications — in particular Communication "A" 8309 (August 2025) and Communications "A" 8381 and 8382 (late 2025) — tightened reporting requirements for payment-account providers and card acquirers. Our integrations are designed so customers can produce the evidence trail (consent logs, transaction timestamps, retention windows) expected under these rules.

On the personal-data side, we align with Argentine Personal Data Protection Law Ley 25.326 and the cross-border flows controlled by the Agencia de Acceso a la Información Pública (AAIP). For EU-origin data (common in Western Union remittance scenarios) we apply GDPR-compatible data-minimization, a lawful-basis register and DPA templates.

We never package credentials, bypass rate limits, or use unauthorized scraping of third-party merchant sites. Integrations are performed under end-user consent or a documented authorization chain, with logging, purpose limitation and revocation endpoints included in every delivery.

Data flow / reference architecture

• 1. Client app / consent UI — the end user or authorized operator grants a scoped consent (read-transactions, read-bills, initiate-transfer).
• 2. Pago Facil adapter — our hosted or self-hosted connector speaks the app's authorized protocol and normalizes responses.
• 3. OpenFinance gateway — exposes REST/JSON to your backend, handles OAuth, rate limiting, signing, and idempotency.
• 4. Storage & analytics — your data lake / ERP / risk engine consumes standardized events and builds dashboards or decisions on top.

The same shape also supports a hybrid model: we run the adapter, you run the gateway behind your own domain to keep data residency inside AR.

Deliverables checklist

• OpenAPI 3.1 spec (YAML) covering auth, bills, wallet, QR, cash, remittance, transfers and webhooks
• Protocol and auth-flow report (OTP, device pin, token lifecycle, error taxonomy)
• Runnable source for login, statement and webhook verification (Python 3.11 + FastAPI and Node.js 20 + Express variants)
• Automated contract & integration tests (pytest / Jest) plus Postman collection
• Compliance pack: BCRA PSPCP note, Ley 25.326 / AAIP data-flow map, consent and retention templates
• Deployment guide for Docker, AWS ECS and Cloudflare Workers

Engagement models

Source code delivery from $300 — we hand over runnable source and full documentation; payment is made after delivery upon satisfaction. Ideal for teams that want full control and an on-prem deployment.

Pay-per-call hosted API — call our managed endpoints and pay only for the calls you make, with no upfront fee. Ideal for teams that prefer usage-based pricing, fast PoCs, or periodic workloads such as month-end reconciliation.

Key integration capabilities

• OAuth-style login with OTP and device binding
• Bill-payment history and receipts
• Wallet ledger, QR payments and normalized transaction feed
• Cash-in/cash-out records tagged by branch
• Inbound Western Union remittance receipts
• Outbound transfers to CBU / CVU / alias with idempotency
• Signed webhooks for real-time events

About our studio

We are an independent technical studio focused on App interface integration and authorized API integration for fintech, e-commerce, travel and OTT apps. Our engineers come from payment gateways, digital banks and protocol-analysis backgrounds, and have shipped integrations across Latin America, Europe and Southeast Asia.

• Domains: payments, digital banking, remittance, cross-border payroll, marketplaces
• Engineering stack: Python, Node.js, Go, Rust for protocol analysis; Terraform + Docker for delivery
• Compliance experience: BCRA, RBI / UPI, PSD2, PIX, GDPR, CCPA and local data laws
• Pipeline: protocol analysis → OpenAPI design → build → validation → compliance review → handover
• Two engagement models: source code delivery from $300 (pay after delivery upon satisfaction) and pay-per-call hosted API with no upfront fee

Contact

Tell us the target app (App Pago Facil) and the data or flows you need — bill-payment export, QR transactions, remittance receipts, outbound transfers, or a full OpenFinance-style bundle. Pricing typically starts at $300 for source code delivery, or pay-per-call billing with no upfront fee for hosted APIs.

Go to contact page

Engagement workflow

1. Scope confirmation: which data sets, authorization path (end-user consent vs. enterprise account), volume and SLAs.
2. Protocol analysis & API design (2–5 business days depending on the number of modules in scope).
3. Implementation and internal validation against staged test accounts (3–8 business days).
4. Documentation, Postman collection, sample code and test cases (1–2 business days).
5. Handover, live walkthrough and post-delivery support window. Typical first delivery: 5–15 business days.

FAQ

What do you need from me to start?

How long does the first delivery take?

How do you handle authorization and privacy?

Can I move between pay-per-call and source-code delivery later?