Pulling crew-pay and transfer records out of Brightwell Navigator

Every payday, a crew member's wages land on an OceanPay card inside Navigator and then fan out — to a home bank account, to cash at a Western Union, MoneyGram or Transfast counter in 130+ countries, or onto a Companion Card for family. That sequence, payroll credit to card to disbursement, is the record worth integrating. Brightwell Payments, Inc. operates the app from Atlanta, and per its Google Play listing it carries pay for 100,000+ cruise-ship crew. The interesting part for an integrator is not a single balance number. It is the event stream: who got paid, how much, in which currency, where it went, and whether it cleared.

This brief maps that stream for one app, names the authorized way to reach it, and states exactly what we hand back. The recommended spine is interface integration under your authorization; the rest of the page explains why and what it produces.

What sits behind a crew member's Navigator login

The app surfaces a small number of high-value record types. Each is a screen a consenting account can see, and that consented view is what we model.

Getting at the record

Two to four routes apply here. They differ in durability and in what they reach.

Authorized interface integration and protocol analysis

We capture the Navigator session a consenting account drives, map the token and second-factor flow, and model the balance, transaction and transfer endpoints into a stable client. This reaches everything a crew member can see, including the OceanPay ledger and the full transfer lifecycle. Effort is moderate; durability is good when paired with the maintenance pass described below. Access to a consenting account or a sponsor test account is arranged with you during onboarding — we handle that setup, you supply the app name and what you want out of it.

User-consented credential access

A consenting crew or sponsor account drives the session for one-off pulls, validation runs, or a low-volume sync. Lower effort, narrower reach, useful as a checkpoint against the integrated client.

Native in-app and web export

The Navigator web platform shows balance and transaction history per the OceanPay program; where an account can download a statement, we use that as a reconciliation source rather than the primary path.

Regulated consumer-data access

OceanPay is a prepaid (Regulation E) account, which fell within the US Section 1033 final rule. Because that rule is currently enjoined and under reconsideration (below), we do not build the spine on it. We design the client so a consent-based channel can be slotted in if and when the rule settles.

For Navigator, the integrated-client route is the one we would carry the project on, with consented credential access used as the validation harness around it. The regulated channel is kept as an option, not a dependency.

What teams build on top of it

• A crewing operator reconciling payroll runs: every credit that hit a crew card per sailing, matched to the disbursement that followed.
• A remittance dashboard that tracks each outbound transfer to paid or returned across all four rails, with the FX rate captured at quote time.
• Proof-of-income exports for crew applying for a mortgage or visa, drawn from payroll-credit history rather than scanned statements.
• A treasury view of aggregate OceanPay float across USD and EUR cards by sponsoring cruise line.
• An AML monitor flagging unusual cash-pickup patterns by corridor.

A session and a statement pull, concretely

Endpoint shapes below are illustrative; the exact paths and fields are confirmed against a consenting account during the build, not published by Brightwell.

POST /auth/session
  body: { device_id, program_code }       # program_code differs per cruise line
  -> 200 { challenge: "facecheck" | "totp", challenge_id }

POST /auth/challenge
  body: { challenge_id, factor_proof }     # video-selfie attestation or TOTP
  -> 200 { access_token, refresh_token, expires_in }

GET /accounts/cards
  Authorization: Bearer <access_token>
  -> 200 [ { card_id, brand:"visa"|"mastercard",
             currency:"USD"|"EUR", status, available_balance } ]

GET /accounts/cards/{card_id}/transactions?from=&to=&cursor=
  -> 200 { items:[ { id, posted_at, amount, currency,
                     type:"payroll"|"purchase"|"atm"|"fee",
                     merchant, running_balance } ],
           next_cursor }

# 401 -> refresh once via /auth/refresh.
# A second 401 means a FaceCheck step-up was forced ->
# re-run /auth/challenge, do not fail the run.
        

Normalizing the disbursement event

The four rails carry different labels. We collapse them into one shape so downstream code is rail-agnostic but never loses the original rail.

{
  "disbursement_event": {
    "event_id": "string",
    "crew_account_ref": "string",
    "program": "carnival|costa|...",
    "rail": "bank_deposit|cash_pickup|recurring|p2p_companion",
    "payout_partner": "western_union|moneygram|transfast|null",
    "amount": { "value": 0, "currency": "USD" },
    "fx": { "quote_rate": 0, "target_currency": "PHP" },
    "status": "quoted|submitted|in_transit|paid|returned",
    "occurred_at": "RFC3339"
  }
}
        

What lands at the end of the engagement

For Navigator specifically, the handover is:

• An OpenAPI specification covering the auth, card, transaction and transfer surfaces as modelled.
• A protocol and auth-flow report: the session establishment, the FaceCheck / TOTP step-up, and the bearer-token refresh chain as they behave on this app.
• Runnable source in Python and Node.js for the key calls — card list, paginated transactions, transfer history, beneficiary list.
• Automated tests, including the re-challenge path and per-currency reconciliation.
• Interface documentation plus the normalized disbursement-event schema.
• Compliance and data-retention guidance scoped to crew financial data and the Bancorp boundary.

Authorization, US data rules, and the Bancorp boundary

Brightwell is a technology provider, not a bank; per its own statements the regulated transfer and card services run through The Bancorp Bank, N.A., which is Member FDIC and where USD account funds are FDIC insured. That boundary matters: card-issuer data and app-surface data are not the same store, and we keep the integration to what a consenting account is entitled to see in the app.

In the US, consumer financial data access sits under CFPB Section 1033. The final rule was published in November 2024, then challenged; per the Federal Register and CFPB, proceedings were stayed in mid-2025, the Bureau opened a reconsideration, and a court later enjoined enforcement pending that review. Because the rule is unsettled, this brief does not treat its specific obligations as binding present-tense fact. Practically, we run on authorized, user-consented access with consent records and request logging, data minimized to the records you actually need, NDA in place where the engagement calls for it. Crew are global, so GLBA-style safeguarding of US financial data and the data-protection law of the crew member's jurisdiction both inform retention.

What we plan around for Navigator

Things this app does that the build accounts for:

• Two card currencies. OceanPay ships a USD card and a EUR EMV card; we key every balance and transaction to its card_id and currency so a USD payroll credit and a EUR card spend reconcile separately instead of summing into a misleading total.
• Step-up authentication. FaceCheck is a video-selfie factor and an authenticator option exists; we design the session around the account's chosen factor and a refresh loop, and treat a mid-session re-challenge as a recoverable event, not a failure.
• Four disbursement rails with different lifecycles. Bank deposit, cash pickup via Western Union / MoneyGram / Transfast, recurring auto-transfer, and Companion Card P2P each report status differently; we normalize them and add a re-validation pass to maintenance so a front-end change is caught before it corrupts a sync.
• Per-sponsor deployment. Navigator is rolled out per cruise line with program-specific rules; we scope the integration per program because eligibility and available rails differ by employer.

Pricing and how the build runs

Two ways to engage. You can take source-code delivery from $300 — runnable client, spec, tests and docs for the surfaces above, and you pay after delivery once it works for you. Or use the hosted API on a pay-per-call basis with nothing upfront, where you call our endpoints and pay only for calls. Either way the cycle is one to two weeks. You give us the app name and what you want from its data; access and the compliance setup are arranged with you as part of the work. Start at /contact.html.

Screens from the app

Where Navigator sits among crew-pay and remittance apps

A unified integration usually spans more than one of these, since crew and the people they pay move between them.

• ShipMoney — the closest peer: maritime crew payroll cards plus bank, e-wallet and cash-pickup remittance across many countries.
• Wise — multi-currency balances and international transfers with per-transaction FX detail.
• Revolut — multi-currency accounts and cards with transaction and transfer history.
• Remitly — consumer remittance with per-transfer status and corridor pricing.
• WorldRemit — cross-border transfers to bank, mobile money and cash pickup.
• MoneyGram — a payout partner here and a standalone transfer app with its own transaction record.
• Western Union — likewise a Navigator cash-pickup partner and a separate sender app.
• Xoom — a PayPal remittance service holding sender history and recipient data.
• Payoneer — cross-border payouts for globally distributed workers, with balance and withdrawal records.

Questions integrators ask about Navigator

Can you separate OceanPay USD card activity from the Euro EMV card on one crew account?

Yes. Navigator runs OceanPay in both a USD and a EUR card variant, so we model each currency as its own ledger and key every transaction and balance to its card_id and currency. Payroll credits, card spend and the FX leg on a transfer reconcile per currency rather than being collapsed into one running figure.

Does the FaceCheck video-selfie or authenticator login block an automated sync?

No. The capture is built around a consenting account and whichever second factor that account uses, with a token-refresh loop. When Navigator forces a FaceCheck step-up mid-session, the sync detects the re-challenge and re-runs the factor instead of failing the run.

Do cash-pickup transfers through Western Union, MoneyGram or Transfast report the same status detail as a bank deposit?

They do not, natively. Each rail has its own lifecycle and labels, so we normalize bank deposit, cash pickup, recurring auto-transfer and Companion Card P2P into one transfer state machine (quoted, submitted, in_transit, paid, returned) and keep the original rail and payout partner as fields.

How do you handle Navigator being deployed differently per cruise line, such as Carnival versus Costa?

We scope the integration per program. Eligibility, disbursement options and enrollment differ by the cruise line that sponsors the account, so the build carries a program code through the session and we validate each program's available rails separately rather than assuming one shape.

How this brief was put together

Checked in May 2026 against Brightwell's Navigator product page and crew material, the Google Play listing for com.brightwellpayments.android, OceanPay / Bancorp and cruise-line distribution announcements, and the Federal Register and CFPB pages tracking Section 1033's status. Sources opened:

• Brightwell Navigator product page
• Brightwell Navigator on Google Play
• Carnival crew-payroll distribution announcement
• Federal Register: Section 1033 reconsideration

Notes by the OpenBanking Studio integration desk, May 2026.