Getting at the salary-advance state behind Adelanta Tu Pago

Every advance request inside Advance - Adelanta Tu Pago settles against an employer payroll cycle, not a credit line — which is what makes its server state worth syncing. A worker opens the app, sees an amount they can pull right now, takes part of it in three taps, and that draw is netted out of their next paycheck. The interesting record for an integrator is not a single balance. It is a moving ledger: how much is available as the pay period elapses, what has been requested, what is scheduled, and what the next payroll run will deduct. Advance your pay Colombia S.A.S. runs this for a reported 200,000-plus employees across Colombian employers, per a Valora Analítik writeup, so the data shape is consistent enough to integrate against once the authenticated surface is mapped.

The bottom line: the high-value object here is the advance ledger plus the live eligibility figure, both of which sit behind an authenticated worker session on the app and the user.adelantatupago.com portal. The route we would actually take is direct interface integration of that consented traffic, with Colombia's open-finance consent rails reserved for the disbursement bank account rather than Advance's own advance records.

What the account actually holds

These are the surfaces a worker sees, named the way the product describes them, mapped to what an integrator does with each.

How we would reach it

Authorized interface integration of the consented client traffic

The app and the worker portal exchange the whole picture — eligibility, request creation, schedules, repayment state, disbursement events — with the backend over an authenticated session. Under the customer's authorization we map that auth flow and those endpoints and rebuild them as a clean client. Reachable: the full authenticated surface. Effort: moderate, mostly auth-flow and endpoint mapping. Durability: solid between front-end releases; we keep a re-check step in maintenance so a changed field surfaces quickly.

User-consented account access

Where you want one worker's record rather than a fleet, the integration runs against a consenting employee's session (or an employer test account set up with you). Good for a read-sync of a single ledger and for proving the field mapping before scale.

Colombia open-finance consent rail

Decreto 1297 de 2022 plus the Superintendencia Financiera's technical standards let a consenting user share data held by a participating bank. That reaches the payroll bank account the advance lands in — useful for settlement confirmation — not Advance's internal advance ledger, which is not bank-held.

Native deduction export

Where an employer's view exposes a payroll-deduction report, a batch export covers reconciliation without live calls. It is a fallback, not the live ledger.

For most buyers the workable core is the first route: the consented client traffic carries everything the ledger needs in one place. We fold the open-finance rail in only when the settlement bank side has to be proven independently, and treat the export as a backstop.

What lands at the end

Tied to this app's real surfaces, the package is:

• An OpenAPI/Swagger spec covering the eligibility lookup, advance-request create, schedule list, repayment state and disbursement-event endpoints.
• A protocol and auth-flow report: the session/token and refresh chain as observed against the worker portal, with the error conditions that matter (cap exceeded, expired session, employer not active).
• Runnable source in Python and Node.js for the two endpoints buyers ask for first — available-amount and request history — with the request lifecycle wired through.
• A normalized schema that maps Advance's fields onto a common earned-wage ledger so this app slots beside other sources.
• Automated tests for the advance lifecycle and the repayment-reconciliation case.
• Interface documentation plus data-retention and consent guidance written against Colombia's Habeas Data regime.

On the wire

Illustrative shape of the eligibility-then-request pair, reconstructed from the authenticated portal flow and confirmed during the build:

# 1) live "available to advance" for the signed-in worker
GET /api/v1/advance/availability
Authorization: Bearer <session_token>

200 OK
{
  "employeeId": "EMP-…",          # employer-scoped
  "payCycle": "monthly",          # or "biweekly"
  "cycleElapsedDays": 17,
  "availableAmount": 480000,      # COP, recomputed as the period elapses
  "perRequestCap": 300000,
  "currency": "COP"
}

# 2) create an advance against that availability
POST /api/v1/advance/requests
Authorization: Bearer <session_token>
{ "amount": 150000, "destination": "payroll_account" }

201 Created
{ "requestId": "ADV-…", "status": "processing",
  "disbursementEta": "PT2H", "repayment": { "deductAt": "next_payroll" } }

# error handling the client must cover
409  amount > perRequestCap | availability stale  -> re-fetch availability
401  session expired                              -> run refresh, retry once
422  employer not active for this cycle           -> surface, do not retry
      

The two states a sync has to hold apart are visible here: availableAmount moves through the cycle, while a created request stays open until the next payroll deducts it. The normalized schema keeps a request from being counted as outstanding and repaid at once.

Where this gets used

• An HR or benefits platform showing each employee a live "available to advance" figure inside its own app, pulled from the eligibility endpoint rather than re-implemented.
• A financial-wellness tool reconciling advances and deductions against payroll runs to show a worker their true net pay for the month.
• A finance team exporting ancillary spend — top-ups, bill pay, subscriptions — per cost center for benefit-budget reporting.

Consent and the Colombian rules that bind this

Advance your pay Colombia S.A.S. runs an employer-mediated payroll-deduction advance with no interest, as the product itself describes it, so it sits beside the regulated-credit perimeter rather than inside it. The personal data is governed by Colombia's Ley 1581 de 2012 (Habeas Data), supervised by the Superintendencia de Industria y Comercio. Colombia's open-finance framework — Decreto 1297 de 2022, with technical and security standards set by the Superintendencia Financiera through External Circular 004 de 2024 — began as a voluntary scheme and has been reported to be moving toward a mandatory model; as that is still in transition we do not treat any specific threshold as settled, and it bears on the linked payroll bank rather than on Advance's own advance records. Our posture for this app is plain: explicit employee authorization, a read scope limited to the ledger fields the project needs, consent and access logs retained, an NDA with the client, and data minimized so ancillary purchase detail is only pulled when the use case calls for it.

Engineering notes specific to this app

Two things shape the build, both handled on our side:

• Pay-cycle skew. Employers run monthly or biweekly cycles, and the available amount is a function of how much of the current cycle has elapsed. We model the per-employer cycle rules so the eligibility figure we expose matches what the worker sees at any point in the month, not just at cycle start.
• Disbursement-to-settlement gap. Money reaches the payroll account in roughly one to two hours while the matching deduction only settles at the next payroll run. We design the sync so an in-flight advance is not double-counted between disbursement and repayment, and so a missed payroll cycle is visible rather than silently dropped.
• Front-end drift. The worker portal can shift between releases. A thin re-check step in maintenance flags a changed endpoint or field fast, so the integration is corrected before downstream reports go wrong. Access for the build is arranged with you during onboarding — a consenting employee account or an employer test account — so the mapping is proven against real responses.

Interface evidence

Store screenshots used while mapping the worker-facing surfaces. Click to enlarge.

Peer apps in the same workforce-pay space

Same category, listed for ecosystem context — a unified earned-wage integration usually has to speak to several of these.

• Minu — Mexico's largest pay-on-demand provider; per-employee earned-wage balances with automated payroll deduction.
• Symplifica — Colombian payroll formalization for domestic workers; its worker app carries payroll advances and benefits.
• Runa — cloud payroll and HR for Latin America; holds the underlying payroll and pay-cycle data an advance is netted against.
• DailyPay — US worktech platform exposing accrued-wage balances and transfer history per worker.
• Branch — operations and wage-access app for hourly staff, with a wallet and earnings ledger.
• Tapcheck — employer-sponsored earned-wage access with a per-employee available-earnings record.
• Wagestream — financial-wellbeing platform combining streamed earnings, savings and pay data.
• EarnIn — paycheck-advance app keyed to worked hours and a linked bank account.
• OrbisPay — daily earned-wage withdrawal with a running accrued-balance ledger.

Questions an integrator of this app tends to ask

Does the advance ledger update through the month, or only at payroll close?

The available-to-advance figure recomputes as the pay period elapses, so it moves through the month against the employer's monthly or biweekly cycle. The repayment side settles only at the next payroll run. We mirror both: the live eligibility number and the pending-deduction state, so a synced ledger never shows an advance as both outstanding and already repaid.

Can you reach one employee's record without touching the employer's payroll system?

Yes. A consenting employee's authenticated session carries the request history, available amount, scheduled advances and disbursement events. The employer payroll feed is only needed if you also want repayment-side reconciliation, and that access is arranged with you during onboarding.

Which Colombian rules govern syncing this data?

The personal data sits under Colombia's Ley 1581 de 2012 (Habeas Data), supervised by the Superintendencia de Industria y Comercio. Colombia's open-finance scheme (Decreto 1297 de 2022, with technical standards from the Superintendencia Financiera) touches the linked payroll bank, not Advance's internal advance ledger. We run scoped, consented, logged access against the ledger fields the project actually needs.

Can you also capture the top-ups, bill payments and subscriptions, or just the advances?

Both. The ancillary purchases (mobile top-ups, data packs, bill pay, streaming subscriptions, transit reload) live on the same authenticated surface as the advances. We map them as a separate spend stream so an integrator can categorize them apart from salary-advance flows.

Start the integration

The deliverable is runnable source for the advance-ledger and eligibility endpoints with an OpenAPI spec, a normalized schema and tests. The source-code engagement is from $300, billed only after delivery once you are satisfied, on a one-to-two-week cycle. The other option is the hosted API: you call our endpoints and pay per call, with nothing upfront. Send the app name and what you need from its data through our contact page and we set up the consented access with you.

Where these findings came from

Checked in May 2026: the Google Play listing for package org.advanceyourpaysas.userapp, the product site and worker portal at adelantatupago.com, a Valora Analítik report on how the salary advance works and its scale, and Colombia's open-finance regulatory material. Specifics on pay cycle, disbursement timing and ancillary services come from those sources rather than from inspection of the production backend.

• Valora Analítik — how Advance / Adelanta Tu Pago works
• adelantatupago.com — product and employer model
• Colombia open finance — Decreto 1297 de 2022 and SFC standards
• Google Play listing

Mapped by the OpenBanking Studio integration desk — reviewed 2026-05-18.