Building an integration that reads a CashPal ProMoney account: the earnings ledger, the referral tree, and the withdrawal queue.

A CashPal account is, mechanically, three things: an event log of rewarded-video credits, a tree of invite codes that fired bonus events, and a small state machine for cashing out. The marketing layer talks about “earn cash by watching short video ads, refer friends, complete bonus tasks” — the integrator’s view is the table behind each of those words. That is what we read, normalize, and ship as a usable API or runnable source against a consenting account.

Per the Play Store summary, the app credits roughly thirty cents per 30–45 second ad, runs a seven-day streak counter, and routes withdrawals through an ID-verification step that user reviews suggest can sit for a while in “pending”. None of that is hostile to integration. It just means the interesting work is the reconciliation, not the raw fetch.

What the account holds

The table maps each surface to where it originates inside the app, the grain at which it is observable, and what a calling system would actually do with it.

How we reach it

Two routes fit this app. Both rest on the same dependable footing: the account holder authorizes the access, the work runs against a logged consenting session, and nothing the studio does sits outside that authorization.

Protocol analysis against a consenting account

We instrument the app’s traffic during a logged session, identify the authentication step and the token lifetime, and map each request that touches the ledger, the referral table, and the withdrawal endpoint. Get-paid-to apps in this size class typically lean on a single JSON API behind a bearer token, plus a server-to-server rewarded-video callback path from the ad mediator — we treat both as part of the surface, because the audit job needs both. Effort: roughly a week to map and a second week to package; durability is medium because consumer mobile titles do reshape endpoints across releases. Access is arranged with the client during kickoff (a sponsor login, a QA account, or a consenting end-user) — that piece is something we set up, not something the reader has to bring on day one.

User-consented credential access

Where the customer wants ongoing per-user sync rather than a one-time pull, the end user authorizes their own CashPal credentials through a consent screen the integration exposes. The integration then calls on their behalf, refreshes tokens against the auth endpoint, and persists only what the consent scope covers. Effort is similar to route one; the extra work sits in the consent UI, the token vault, and the revocation path. Durability is the same.

Of the two, the recommendation for almost every CashPal use case is route one for the build itself — it is faster, cheaper, and produces the OpenAPI a calling team can read. Layer route two on top later only if and when an ongoing per-end-user feed is the actual product.

A look at the wire

The shape below is the pattern we usually find for an Android-first rewards app like this; the exact host, paths, and field names are confirmed during the build against CashPal’s own traffic. The auth method, the bearer-token lifetime, and the withdrawal state names go into the OpenAPI verbatim once the mapping is locked.

POST /v1/auth/login
Content-Type: application/json
X-App-Version: <build>
X-Device-Id:  <install fingerprint>

{ "email": "...", "password": "...", "device": { "id": "...", "os": "android" } }

=> 200 OK
{ "token": "<jwt-ish bearer>", "user_id": "...", "expires_in": 3600 }

# subsequent calls: Authorization: Bearer <token>

GET  /v1/wallet/balance
GET  /v1/wallet/ledger?since=<epoch>&limit=100
GET  /v1/referrals?hop=1
GET  /v1/tasks/streak
GET  /v1/withdrawals?state=pending,id_required,under_review,paid

POST /v1/withdrawals
{ "amount_cents": 5000, "rail": "paypal", "destination": "user@example.com" }

# rewarded-video SDK side, captured for the audit:
# POST {your_endpoint}  ?event_id=...&user_id=...&amount=...&signature=...
# Acknowledge with HTTP 200 carrying "[EVENT_ID]:OK" per the mediator’s contract.

The last block is the reconciliation hook. The mediator’s server-to-server callback is what an ad network considers the source of truth for a paid view, so an integration that quietly compares it against the wallet ledger is the one that catches credits that fired on the network side but never landed in the user’s balance, and the reverse.

The handoff

For CashPal specifically, the deliverable bundle looks like this:

• An OpenAPI 3.1 spec covering the auth flow, the wallet endpoints, the referral tree, the streak/task endpoints, and the withdrawal state machine — the exact state names are part of the document, not implied.
• A protocol report that walks the login chain, the bearer-token refresh, the rewarded-video server-to-server callback shape, and the request signatures that the live app sends.
• Runnable source in Python (and Node.js on request) for each endpoint, with a small CLI that pulls a full account snapshot end-to-end against a real login.
• Automated tests: a recorded-traffic suite that runs offline, plus a smoke pass that hits the live endpoints with a consenting account.
• A short interface document a non-author engineer can read and ship from — including the reconciliation pattern between the SDK callback and the wallet ledger.
• Notes on consent scope, retention, and what to log on the calling side so a user can later exercise a data-deletion request and the integration cooperates.

Notes from the engineering side

Four things we plan around when we build against CashPal-class apps. None of these are barriers — they are the small calls that make the build hold up.

• Credit-vs-callback drift. The wallet ledger reflects what the app awarded; the ad mediator’s server-to-server callback reflects what the network believes it paid for. We model both and ship the diff endpoint as a first-class part of the integration, because that diff is exactly the audit the customer usually came in for.
• The withdrawal state machine. User reviews on the listing describe cashouts sitting in “pending” while ID verification is in flight, occasionally beyond the two-week window the app communicates. We name each state explicitly in the spec — pending, id_required, under_review, paid, rejected — and the source handles each one rather than collapsing them into a generic “in progress”, so a calling system can tell a user something meaningful.
• Release churn. Endpoints and request signatures shift across consumer-app releases. The handoff includes a small re-validation pass that runs against the live build, flags the first endpoint that changes shape, and produces a focused diff so a maintenance touch is hours, not days.
• Referral depth. First-hop referees and their bonus events are observable from a single account login; deeper hops sit behind those users’ own accounts. We scope the deliverable to what the chosen route can actually see and say so plainly in the spec, so nobody calls the integration looking for a number that was never on this side of the auth boundary.

Consent and privacy regime

CashPal is not a regulated financial data provider, so the AIS-style consent regimes that govern open banking do not bind this build. The dependable basis is the account holder’s own authorization — the customer-side sponsor login for route one, the end-user consent screen for route two. On top of that, the build operates under whichever privacy regime the user residency triggers: COPPA if any account holder is under 13, CCPA for California residents, GDPR for users in scope, and the standard mobile-platform expectations elsewhere. Practically, that means the integration logs which scope the user granted, retains the minimum the calling system actually needs, and routes a deletion request through the same path that produced the data. NDAs cover the work where the customer prefers a written one. Everything else — sandbox, test logins, the consent flow itself — is set up with the client during kickoff.

How the engagement runs

The work runs against the client’s own goal: a snapshot pull, a per-end-user sync, an audit against the ad mediator, or some mix. From there it is one of two simple shapes. Source delivery starts at $300: we hand over the spec, the runnable source, the tests, and the documentation, and the client pays after delivery once the bundle is working. Pay-per-call skips the upfront and bills the calling team for the API calls they actually make against our hosted endpoints. Cycle in both shapes is 1–2 weeks. Send us the app name and what you want out of it and we will come back with the route, the cycle, and a fixed number.

Where this came from

What was checked against primary sources for this page: the app’s own Google Play listing (category, package id, and the public-facing summary of how the rewards and withdrawal flow work, including the ID-verification step described in user reviews); the IronSource server-to-server callback documentation, which is the canonical contract a rewarded-video mediator uses when it tells an app a view was paid; and the FTC’s COPPA FAQ as the reference for the children-online-privacy obligations that any US-distributed rewards app must take seriously. Specific numeric details (download band, exact rating, exact per-ad credit) are not asserted as flat fact on this page beyond what the Play Store listing itself shows.

Mapping notes from OpenBanking Studio’s integration desk — last revisited May 2026.

Other apps in the same shelf

If a calling team wants one unified view across the get-paid-to category, these are the names the same integration pattern applies to. Listed for ecosystem context; no ranking is implied.

• Mistplay — play-to-earn loyalty across a curated game roster; ledger plus units-to-cash conversion behind the account.
• JustPlay — minimum-cashout-light variant of the same shape; PayPal payout flow.
• Cashyy — gameplay-time credits with a coin ledger backing them.
• AppStation — install-and-play offer wall with a $10 PayPal cashout threshold.
• Cash Giraffe — gameplay-time credits with one of the lower observed cashout thresholds.
• KashKick — quizzes, videos, referrals, with a $10 PayPal threshold.
• Swagbucks — broader get-paid-to platform; surveys, videos, shopping, with PayPal and gift cards.
• Freecash — offers, surveys, games; supports PayPal, bank, and crypto payouts.

Questions that come up first

Can the integration tell paid ad-views apart from credited ad-views?

Yes — that gap is the single most useful audit a CashPal integration produces. We capture the rewarded-video SDK’s server-to-server callback alongside the in-app credit event, and a reconciliation pass surfaces any view that fired the SDK callback but never landed on the wallet ledger (or vice versa).

How do you handle the ID-verification step in the withdrawal flow?

The cashout endpoint puts requests into a queue that flips between states (pending, ID requested, under review, paid, rejected). The integration models that state machine explicitly so a calling system can show a withdrawal as 'awaiting ID' instead of just 'pending', and so a re-attempt does not double-submit. We confirm the exact state names against the live build.

What happens to the integration when CashPal pushes an app update?

Endpoints and headers can shift between releases — that is part of working with consumer mobile titles. The handoff includes a small re-validation harness that hits the key surfaces and flags differences, so a release rarely breaks more than one endpoint at a time and the fix is scoped.

Can we pull the full referral tree for one account, or only direct invitees?

From a single account login the directly observable layer is the first hop — the people that account invited, with their bonus events. Second-hop referees usually require a separate consenting login at that level. We map this on day one so the deliverable matches what is actually reachable, not what the marketing copy implies.