diff --git a/AGENTS.md b/AGENTS.md
index 2fae08f..68f281b 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -8,12 +8,13 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
## Current strategic thesis
-- Start in Brazil.
-- Lead with `Pix`-based instant access to earned commissions.
+- Keep the core product geography-agnostic.
- Use a regulated financial partner for custody, payouts, card issuance, and compliance.
+- Lead with fast access to earned commissions over the relevant local payout rail.
- Treat cards and stored balances as later retention tools, not the initial wedge.
- Treat advances as a later employer-backed feature, not the first product.
- Build employer analytics from payment-linked data.
+- Keep market-specific assumptions in `docs/countries/`.
## What this company is
@@ -36,21 +37,19 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
## Key documents
- `docs/core-idea.md` - canonical summary of the product and business model
-- `docs/brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR
- `docs/market-memo.md` - competitor map, differentiation, and investor-style memo
- `docs/positioning-and-landing-copy.md` - messaging and homepage copy directions
- `docs/year-one-roadmap.md` - phased roadmap for the first year
+- `docs/prototype-plan.md` - prototype scope, flows, and build sequence
- `docs/ideas-for-review.md` - review file for ideas not yet integrated into the core docs
+- `docs/countries/brazil.md` - Brazil-specific thesis and go-to-market notes in pt-BR
+- `docs/countries/switzerland.md` - Switzerland-specific thesis and go-to-market notes
## Language conventions
- Write in English by default.
-- Keep `docs/brazil-market.md` in pt-BR.
-- Keep fintech terminology consistent: `Pix`, `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.
-
-## Transcripts
-
-- Transcripts of previous sessions are available under the sessions/ subdir, in case extra context is necessary.
+- Country-specific docs may use local language where helpful.
+- Keep fintech terminology consistent: `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`, `instant payout rail`.
## Product assumptions to preserve
@@ -59,6 +58,7 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
- The payment event is the source of truth for commission creation whenever possible.
- The employer buyer needs controls, auditability, and analytics, not just a payout rail.
- The employee experience matters because faster access and later card usage can improve retention and platform utility.
+- Country-specific differences should be layered on top of the same core ledger and workflow model.
## Reference competitors and adjacent players
@@ -69,22 +69,21 @@ Use this current market framing unless new evidence clearly changes it:
- `PayQuicker`
- `Hyperwallet`
- `CaptivateIQ`
-- `Caju`
-- `Dock`
-These companies validate parts of the stack, but the current thesis is that few combine payment-linked commissions, worker liquidity, employer controls, and Brazil-native rails into one product.
+Country-specific employer-finance apps, PSPs, BaaS providers, and issuers should be documented in the relevant country notes rather than the core docs.
## Prioritization guidance for future agents
-- Prioritize docs and plans that sharpen the Brazil-first wedge.
+- Prioritize docs and plans that sharpen the geography-agnostic core product.
+- Keep country-level launch assumptions, partners, and regulation in `docs/countries/`.
- Keep the distinction between `earned access` and `credit` very clear.
- Prefer practical operator language over generic fintech buzzwords.
- If you extend product plans, sequence features conservatively: ledger and instant payouts first, analytics and stored balance second, cards third, employer-backed advances later.
## Open areas worth exploring later
-- deeper regulatory mapping for Brazil launch structure
-- partner comparison across BaaS, payment processors, and card issuers
+- deeper regulatory mapping for Brazil, Switzerland, and future launch structures
+- partner comparison across local banking, payment processing, and card issuance stacks
- pricing design for employers versus workers
- reserve rules for refunds, disputes, and chargebacks
- target vertical selection and design-partner outreach strategy
diff --git a/README.md b/README.md
index a061377..24923a5 100644
--- a/README.md
+++ b/README.md
@@ -1,28 +1,31 @@
-# Payroll Planning Workspace
+# Commission Infrastructure Planning Workspace
-Documentation-first workspace for a Brazil-first B2B2C fintech concept focused on payment-linked commissions, instant access to earned balances, and employer controls around payouts and analytics.
+Documentation-first workspace for a location-independent B2B2C fintech concept focused on payment-linked commissions, fast access to earned balances, and employer controls around payouts and analytics.
## Document index
- `docs/core-idea.md` - canonical summary of the product, operating model, and money flow
-- `docs/brazil-market.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR
- `docs/market-memo.md` - market gap, competitor map, differentiation, and business model framing
- `docs/positioning-and-landing-copy.md` - messaging directions, landing-page copy, and narrative structure
- `docs/year-one-roadmap.md` - phased plan for the first year of product and partner execution
- `docs/prototype-plan.md` - proposed scope, flows, architecture, and build sequence for a first product prototype
- `docs/ideas-for-review.md` - ideas from external conversations that are not yet part of the core docs
+- `docs/countries/README.md` - index for country-specific market notes
+- `docs/countries/brazil.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR
+- `docs/countries/switzerland.md` - Switzerland-specific thesis, local constraints, and go-to-market notes
## Suggested reading order
- `docs/core-idea.md`
-- `docs/brazil-market.md`
- `docs/market-memo.md`
- `docs/positioning-and-landing-copy.md`
- `docs/year-one-roadmap.md`
- `docs/prototype-plan.md`
+- `docs/countries/README.md`
## Notes
-- Write in English by default; keep `docs/brazil-market.md` in pt-BR.
+- Write in English by default. Country-specific docs may use local language where helpful.
+- Keep fintech terminology consistent: `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.
+- Country-specific launch assumptions, partners, and regulatory notes belong in `docs/countries/`.
- The repository currently holds strategy and planning documents, not production code.
-- Session transcripts live under `sessions/`.
diff --git a/docs/core-idea.md b/docs/core-idea.md
index 59a8d85..14d99af 100644
--- a/docs/core-idea.md
+++ b/docs/core-idea.md
@@ -53,7 +53,7 @@ The product sits between customer payment collection and employer payout.
### Instant access rails
-- Start with instant bank transfer or `Pix` cash-out.
+- Start with instant or fast bank-transfer cash-out on the relevant local rail.
- Later add stored balance inside the app.
- Later add a prepaid or debit card linked to the balance.
@@ -74,12 +74,12 @@ The safest early structure is partner-led custody.
- A regulated bank or licensed financial partner holds funds.
- The platform owns the application layer, commission logic, ledger, and payout orchestration.
-- Cards, `Pix`, KYC, and regulated money movement are handled through partners.
+- Cards, local payout rails, KYC, and regulated money movement are handled through partners.
Example flow:
```text
-Customer pays R$1,000
+Customer pays 1,000 in local currency
|
v
Partner-held account receives funds
@@ -87,8 +87,8 @@ Partner-held account receives funds
v
Commission engine calculates split
|
- +-- Employee commission: R$200
- +-- Employer balance: R$800
+ +-- Employee commission: 200
+ +-- Employer balance: 800
+-- Platform fee and reserve logic applied
|
v
@@ -189,9 +189,10 @@ The company is best understood as `commission infrastructure`.
## Current strategic recommendation
-- Start in Brazil.
-- Lead with `Pix`-based instant access to earned commissions.
+- Keep the core ledger, commission logic, and employer workflows geography-agnostic.
+- Choose launch markets based on payment-event traceability, employer pain, partner availability, and local payout rails.
- Use partner-led custody and compliance.
+- Lead with fast access to earned commissions over the relevant local rail.
- Treat stored balances and cards as retention tools, not the initial wedge.
- Treat employer analytics as a second major value driver.
- Delay true lending until the core ledger and payout engine are reliable.
diff --git a/docs/countries/README.md b/docs/countries/README.md
new file mode 100644
index 0000000..5d63531
--- /dev/null
+++ b/docs/countries/README.md
@@ -0,0 +1,19 @@
+# Country Notes
+
+Core planning docs in `docs/` should stay geography-agnostic. Country-specific launch assumptions, payout rails, partner choices, regulatory notes, and go-to-market details belong in this directory.
+
+## Current dossiers
+
+- `brazil.md` - Brazil-specific notes in pt-BR, centered on `Pix`, local partner choices, and launch considerations
+- `switzerland.md` - Switzerland-specific notes in English, centered on bank-based payouts, compliance expectations, and launch considerations
+
+## Supporting reports
+
+- `brazil-partners.md` - Expanded partner landscape for Brazil, including Dock, QI Tech, Bankly, Pismo, Celcoin, and specialist watchlist options
+- `switzerland-partners.md` - Expanded partner landscape for Switzerland, including HBL Solutions, Yapeal, SIX b.Link, Swisscom, and adjacent options
+
+## Guidance
+
+- Add new countries as separate files rather than baking local assumptions into the core docs.
+- Keep the core product thesis, ledger model, and employer workflow consistent across countries.
+- Document local rails, regulation, partner dependencies, and target verticals here.
diff --git a/docs/countries/brazil-partners.md b/docs/countries/brazil-partners.md
new file mode 100644
index 0000000..0e369b0
--- /dev/null
+++ b/docs/countries/brazil-partners.md
@@ -0,0 +1,973 @@
+# Brazil partner report
+
+This report expands the initial Brazil shortlist into a more decision-useful view of the partner landscape for our commission infrastructure thesis.
+
+Brazil is structurally different from Switzerland.
+
+Because `Pix` already sets strong expectations around real-time money movement, the most important question is not whether the market understands instant payouts. It does. The question is which partners can let us deliver that experience with:
+
+- a compliant launch structure under a regulated partner
+- reliable employer and worker onboarding
+- auditable commission-ledger integration
+- 24/7 `Pix` cash-out to the worker
+- later support for stored balance and card issuance
+
+## Executive summary
+
+### Best one-provider launch cluster
+
+If we want the fastest route to live pilots with the fewest moving parts, the strongest Brazil candidates are now better framed as a **cluster**, not just a top three:
+
+- **Dock**
+- **QI Tech**
+- **Bankly**
+- **Celcoin**
+
+These are the clearest current candidates for the regulated account, `Pix`, and later-card story in one operating setup.
+
+### Strong additional alternatives worth diligence
+
+The strongest additional names to add to the comparison set are:
+
+- **FitBank**
+- **Z.ro Bank**
+- **Zoop**
+
+These are not all equal in fit, but they are credible enough to keep in the active Brazil landscape.
+
+### Best modular architecture option
+
+If we want a more configurable stack rather than a single all-in-one vendor, the strongest architecture path is still:
+
+- **Pismo** as the modern core technology layer
+- **Celcoin** as the licensed BaaS layer
+
+That pairing remains notable because Pismo's own documentation explicitly says it is **not a licensed bank** and works with BaaS partners such as **Celcoin**.
+
+### Specialist adjacencies to keep warm
+
+- **Pomelo** for card specialization
+- **Transfeera** for payout and collections operations
+- **PagBrasil** for local payments and Automatic Pix adjacencies
+
+### Main conclusion
+
+For Brazil, the right structure is:
+
+1. run a one-provider comparison wave across **Dock, QI Tech, Bankly, and Celcoin**
+2. keep **FitBank** and **Z.ro Bank** in the alternative set
+3. evaluate **Pismo + Celcoin** in parallel if we want a split-stack architecture
+4. treat **Pomelo, Transfeera, Zoop, and PagBrasil** as specialists or adjacencies unless the pilot shape pulls them forward
+
+---
+
+## What our product needs from a Brazil partner
+
+### Must-have at launch
+
+1. **24/7 `Pix` payouts**
+ - Our wedge is access to earned commissions through the local instant rail.
+ - The partner must support high-volume, always-on `Pix` disbursement.
+
+2. **PF and PJ onboarding**
+ - Employer KYB and worker KYC need to be production-grade.
+ - Weak onboarding will kill pilot velocity.
+
+3. **Programmable ledger-adjacent workflows**
+ - We keep our own commission ledger logic.
+ - The partner must expose enough API surface to support:
+ - balance creation and movement
+ - payout requests
+ - payout status
+ - transaction eventing
+ - reversals, disputes, and adjustments where applicable
+
+4. **Reserve and exception handling**
+ - Brazil requires explicit handling for:
+ - refund requests
+ - `Pix` infractions
+ - chargebacks when commission creation is tied to card payments
+ - employer clawback and holdback logic
+
+5. **External account cash-out**
+ - At launch, the worker should be able to receive money in an existing account through `Pix`.
+ - We should not require the worker to adopt a new full banking relationship just to use the product.
+
+### Important, but can come later
+
+1. stored balance / wallet behavior
+2. debit or prepaid card issuance
+3. limited-use or incentive-style card products
+4. employer-backed advance products
+5. deeper acquiring or bill-collection integration
+
+### Not worth leading with
+
+1. consumer lending
+2. generic digital-bank positioning
+3. a card-first user story before the `Pix` payout workflow works well
+
+---
+
+## Brazil market reality for partner selection
+
+Brazil is a much richer partner environment than Switzerland for this thesis.
+
+### Why that matters
+
+There are more credible ways to assemble the stack:
+
+- all-in-one BaaS
+- bank-licensed API platforms
+- core-banking-plus-licensed-partner combinations
+- card specialists that can be added later
+- payout and collections specialists that can support a narrower launch scope
+
+### What this means for us
+
+We should be explicit about which route we prefer.
+
+## Route A: fastest path to launch
+
+Pick a single partner that can cover:
+
+- accounts
+- `Pix`
+- onboarding and compliance support
+- reporting
+- later cards
+
+This is the most attractive route if speed and operational simplicity matter more than technical purity.
+
+## Route B: most configurable architecture
+
+Use:
+
+- a modern core platform for accounts, events, `Pix`, cards, and controls
+- a licensed BaaS provider for the regulated layer
+
+This is attractive if we want more control over product behavior and are comfortable managing two vendors.
+
+## Route C: narrower `Pix`-first launch scope
+
+Use a payout-led or payment-led provider when the pilot scope is intentionally narrow:
+
+- external `Pix` cash-out first
+- limited or no stored-balance behavior at launch
+- cards explicitly later
+
+This can be viable for some design-partner pilots, but only if it does not weaken the core commission-ledger thesis.
+
+---
+
+## Evaluation criteria
+
+| Criterion | Why it matters for us |
+| --- | --- |
+| `Pix` execution and uptime | The core user promise in Brazil is instant access to earned money |
+| Regulatory structure | We want to launch under a regulated partner rather than direct custody |
+| PF/PJ onboarding | Employer and worker onboarding speed affects pilot success |
+| API and event maturity | We need programmable workflows, not manual back office dependence |
+| Reversals / disputes / fraud controls | Essential when payouts can happen before final settlement certainty |
+| Card readiness | Important for later retention, but not the launch wedge |
+| Sandbox and developer docs | Important for rapid iteration and partner diligence |
+| Commercial fit | Minimums and implementation complexity can kill an otherwise good choice |
+
+---
+
+## Public-evidence scorecards
+
+**Legend:** `High` = strong fit from reviewed official materials, `Medium` = partial fit or meaningful gaps still unclear, `Low` = weak public evidence for this use case.
+
+### Full-stack / launch-core scorecard
+
+| Partner | Regulated layer | `Pix` depth | Accounts / KYC fit | API / docs quality | Card path | Current priority |
+| --- | --- | --- | --- | --- | --- | --- |
+| **Dock** | High | High | High | Medium | High | **Priority 1** |
+| **QI Tech** | High | High | High | Medium | Medium | **Priority 1** |
+| **Bankly** | High | High | High | High | Medium | **Priority 1** |
+| **Celcoin** | High | High | High | High | High | **Priority 1/2** |
+| **FitBank** | Medium | High | Medium | High | Medium | **Priority 2** |
+| **Z.ro Bank** | Medium | High | Low-Medium | High | Low | **Priority 2/3** |
+| **Zoop** | Medium | Medium-High | Medium | High | Medium | **Priority 3** |
+
+### Split-stack / specialist scorecard
+
+| Partner | Best role | Regulated layer | `Pix` / payout depth | Card depth | API / docs quality | Current priority |
+| --- | --- | --- | --- | --- | --- | --- |
+| **Pismo** | Core technology platform in split stack | Low as standalone | High | High | High | **Priority 1 for split-stack** |
+| **Pomelo** | Card issuing / processing specialist | Low | Low | High | Medium | Watchlist |
+| **Transfeera** | `Pix` payouts / collections adjunct | Medium | High | Low | High | Priority 3 |
+| **PagBrasil** | Local payments / Automatic Pix adjunct | Low | Medium | Low | Medium | Watchlist |
+
+---
+
+## Shortlist at a glance
+
+| Partner | Type | Best role in our stack | Public-evidence launch fit | Public-evidence later fit | Overall priority |
+| --- | --- | --- | --- | --- | --- |
+| **Dock** | Full-stack banking, `Pix`, cards, fraud, acquiring | Single-provider launch partner | **High** | **High** | **Priority 1** |
+| **QI Tech** | BaaS and regulatory / tech infrastructure | Single-provider launch partner | **High** | High | **Priority 1** |
+| **Bankly** | BaaS platform with banking license and direct `Pix` participation | Single-provider launch partner | **High** | High | **Priority 1** |
+| **Celcoin** | Licensed BaaS / core banking / cards | Single-provider alternative or licensed layer behind Pismo | High | High | **Priority 1/2** |
+| **Pismo** | Core banking / cards / `Pix` technology platform | Technology core in split-stack model | Medium as sole partner | **High** | Priority 1 for split-stack |
+| **FitBank** | BaaS / `Pix` / onboarding / prepaid card infrastructure | Alternative one-provider path | Medium | Medium-High | Priority 2 |
+| **Z.ro Bank** | Digital bank, Pix-as-a-Service, gateway, crypto / payments infrastructure | Alternative `Pix`-first path | Medium-Low | Medium | Priority 2/3 |
+| **Zoop** | Banking + payments + split infrastructure | Alternative if payment splits and marketplace logic matter | Medium-Low | Medium | Priority 3 |
+| **Transfeera** | Payments API / `Pix` / boleto / payout ops | Payout and collections adjunct | Low as sole core | Medium | Priority 3 |
+| **Pomelo** | Card issuing / processing specialist | Later-stage card specialist | Low | High | Watchlist |
+| **PagBrasil** | Local payments / `Pix` specialist | Collection or local payment adjunct | Low | Medium | Watchlist |
+
+---
+
+## Detailed partner assessments
+
+## 1. Dock
+
+### What it is
+
+Dock is the clearest all-in-one Brazil option in the current shortlist.
+
+Its public materials show meaningful breadth across:
+
+- digital accounts
+- `Pix`
+- cards and processing
+- fraud prevention
+- treasury and reconciliation support
+- white-label financial products
+
+### What the official materials clearly show
+
+Dock states that it offers:
+
+- white-label digital banking with digital account, cards, `Pix`, slips, and related features
+- a base of **over 75 million active accounts**
+- `Pix` capabilities including:
+ - becoming an **indirect participant**
+ - QR code generation
+ - `Pix` as payment method
+ - `Pix` on bills and slips
+ - automatic `Pix`
+- more than **1 billion `Pix` transactions** processed in the last year according to its `Pix` materials
+- white-label cards with:
+ - physical and virtual cards
+ - branded cards
+ - prepaid and debit options
+ - Visa, Mastercard, Amex, and Elo access
+- card-processing support including settlement, reconciliation, chargeback management, and balance-impacting transaction management
+- support for **multi-benefit cards** and other workforce-adjacent products
+
+### Why it fits our thesis
+
+Dock matches our roadmap unusually well:
+
+- `Pix`-first payout wedge
+- later stored-balance and card layer
+- employer workflow potential
+- regulatory and operational cover under a third-party provider
+
+The workforce-adjacent products are especially interesting.
+
+Its multi-benefit and payroll-adjacent materials suggest it already understands employer-to-worker financial flows, even if our product is a commission infrastructure product rather than a classic benefits card.
+
+### Best role in our stack
+
+**Single-provider launch partner** for:
+
+- accounts and balances
+- `Pix` disbursement
+- onboarding support
+- future prepaid/debit card program
+- treasury and reconciliation support
+
+### Main questions to validate
+
+1. Can Dock support an employer-funded commission access model without forcing a full consumer-bank UX on day one?
+2. Can we keep our own commission ledger while using Dock only for regulated balances and money movement?
+3. What account structure works best: employer master account plus worker accounts, or a pooled model with payout instructions?
+4. How configurable are payout rules, approval steps, and holdbacks?
+5. Can we start with `Pix`-out only and add cards later without re-architecting?
+6. What are the commercial minimums and implementation timelines for an early-stage company?
+
+### Assessment
+
+**Strongest all-in-one Brazil candidate.**
+
+If we want one partner that can plausibly get us from pilot to later card products, Dock is the first call.
+
+---
+
+## 2. QI Tech
+
+### What it is
+
+QI Tech presents itself as a BaaS platform with both technology and regulatory infrastructure.
+
+### What the official materials clearly show
+
+QI Tech states that its BaaS offering can support:
+
+- card issuing
+- payments
+- digital accounts
+- credit
+- individual or linked accounts
+- broader financial operations through a single BaaS setup
+
+Its `Pix` materials also highlight:
+
+- a solution to operate as an **indirect `Pix` participant**
+- **high-availability APIs**
+- **direct connection to the Central Bank**
+- regulatory and compliance support
+- modular account architecture or use of QI Tech's own core
+- dedicated onboarding, implementation, and support squads
+
+### Why it fits our thesis
+
+QI Tech looks like a strong middle ground between:
+
+- a pure full-stack provider like Dock
+- and a more modular architecture like Pismo + Celcoin
+
+It appears capable of supporting the launch wedge directly while still offering architectural flexibility.
+
+### Best role in our stack
+
+**Single-provider launch partner** for:
+
+- `Pix`
+- account infrastructure
+- onboarding and compliance support
+- later cards
+- potentially more advanced financial products if we ever need them
+
+### Main questions to validate
+
+1. How opinionated is the account architecture for a B2B2C employer-sponsored use case?
+2. What does worker onboarding look like in practice for a commission payout flow?
+3. Can we run `Pix` cash-out without forcing full-featured digital accounts from day one?
+4. How strong are reporting, webhooks, and reconciliation for employer operations?
+5. What are the real implementation timelines for a startup-scale pilot?
+
+### Assessment
+
+**Top-tier Brazil candidate.**
+
+QI Tech deserves to be in the first wave of outreach, especially if we want a serious regulated partner that still feels modern and API-first.
+
+---
+
+## 3. Bankly
+
+### What it is
+
+Bankly is especially notable because its official materials explicitly describe it as a **technology company with a banking license**.
+
+That makes it one of the cleaner one-partner stories in Brazil.
+
+### What the official materials clearly show
+
+Bankly states that it offers:
+
+- a BaaS platform with **more than 30 APIs**
+- a complete digital account
+- card issuing within Mastercard's network
+- bank slip issuance
+- TED transfers
+- sandbox access
+- individual and business account opening
+- individual and business KYC
+- direct participation in **`Pix`**
+- connection to the **Brazilian Payment System (SPB)** with a settlement account and bank number
+
+### Why it fits our thesis
+
+Bankly checks many launch boxes cleanly:
+
+- regulated story
+- direct `Pix` participation
+- PF and PJ onboarding
+- cards later
+- documented API surface and sandbox
+
+That is particularly compelling for a company that wants to ship a commission infrastructure product without managing too many counterparties.
+
+### Best role in our stack
+
+**Single-provider launch partner** for:
+
+- worker payouts by `Pix`
+- employer and worker onboarding
+- account support
+- card issuance later
+- core banking primitives for the regulated layer
+
+### Main questions to validate
+
+1. How flexible is Bankly's model for employer-funded balances and worker-visible earnings?
+2. Can payouts be done to external `Pix` keys without requiring a full account-first experience?
+3. What controls exist for reserves, payout limits, and employer approval chains?
+4. How mature is support for webhook-driven operational workflows?
+5. How does Bankly compare commercially with Dock and QI Tech for an early-stage pilot?
+
+### Assessment
+
+**Strong first-wave candidate.**
+
+Bankly looks particularly attractive if we want a simple story: bank-licensed infrastructure, direct `Pix`, cards later, documented APIs.
+
+---
+
+## 4. Pismo
+
+### What it is
+
+Pismo is a modern core banking, cards, and payments technology platform.
+
+But the key nuance is important:
+
+**Pismo explicitly says it is not a licensed bank and does not directly implement BaaS.**
+
+That means Pismo should not be evaluated as a standalone regulated partner.
+
+### What the official materials clearly show
+
+Pismo's official documentation states that, with a partnering BaaS provider, it can support:
+
+- organization, program, and account setup
+- `Pix` instant payments
+- boleto payments
+- P2P transactions
+- cash-out transfers to external accounts
+- reporting and eventing
+- transaction validation, anti-fraud, and KYC-related support
+
+Its `Pix` documentation also shows unusually rich operational depth, including:
+
+- `Pix` key management
+- `Pix` in and out
+- reversals
+- scheduled and recurring `Pix`
+- infraction reports
+- refund requests
+- anti-fraud webhooks
+- dynamic QR and BR code generation
+
+Its card documentation shows support for:
+
+- physical and virtual cards
+- prepaid, debit, credit, and private label
+- tokenization and wallet support
+- configurable limits and lifecycle controls
+
+### Why it fits our thesis
+
+Pismo is attractive if we want a highly programmable core that can support:
+
+- internal commission-ledger logic on our side
+- flexible event-driven workflows
+- deep `Pix` operations
+- future card issuance with strong controls
+
+### Best role in our stack
+
+**Technology core** in a split-stack model, typically with a regulated BaaS partner such as Celcoin.
+
+### Main drawback
+
+Pismo adds architectural power, but also more complexity.
+
+We would need to coordinate at least:
+
+- the core technology provider
+- the licensed BaaS partner
+- commercial and operational responsibility boundaries between them
+
+### Assessment
+
+**Excellent technology platform, but not the sole launch partner.**
+
+Pismo makes the most sense if we intentionally choose a split-stack architecture.
+
+---
+
+## 5. Celcoin
+
+### What it is
+
+Celcoin is important for two reasons:
+
+1. it appears to be a capable BaaS and core-banking provider in its own right
+2. it is explicitly named by Pismo as one of the BaaS partners used to enable banking services
+
+That makes Celcoin strategically relevant even if we never choose Pismo.
+
+### What the official materials clearly show
+
+Celcoin's documentation states that BaaS clients can integrate using **Celcoin's banking license** and infrastructure.
+
+The official docs and product pages show support for:
+
+- onboarding and KYC
+- account creation and management
+- balance and statement reporting
+- webhooks
+- `Pix` in and `Pix` out
+- `Pix` key registration and portability
+- TED transfers
+- collections and bill payments
+- white-label card issuance
+- physical and virtual cards
+- prepaid and postpaid cards
+- recurring and temporary virtual cards
+- combined card modes in some setups
+
+Its BaaS product page also emphasizes:
+
+- integrated onboarding
+- Open Finance support
+- transfer and bill-payment capabilities
+- Visa credit-card support
+- developer-oriented documentation, samples, and real-time webhooks
+
+### Why it fits our thesis
+
+Celcoin can be viewed in two ways:
+
+1. **standalone candidate** for launch
+2. **licensed layer** in a more modular architecture
+
+That flexibility is valuable.
+
+### Best role in our stack
+
+Either:
+
+- **single-provider launch partner** if commercial and operational fit is good enough
+- or **licensed BaaS layer behind Pismo** if we want a more configurable stack
+
+### Main questions to validate
+
+1. How strong is Celcoin as the main operator for a B2B2C employer-driven payout workflow?
+2. Can it support the separation we need between our commission ledger and the regulated balance layer?
+3. How much product logic can be encoded without custom services work?
+4. If paired with Pismo, where do responsibilities split for support, fraud, reversals, and reconciliation?
+
+### Assessment
+
+**High-value candidate and important architecture enabler.**
+
+Even if we do not choose Celcoin alone, it belongs in the first serious architecture conversations.
+
+---
+
+## 6. Pomelo
+
+### What it is
+
+Pomelo appears strongest as a card issuing and processing specialist for Latin America.
+
+The evidence we reviewed points to:
+
+- issuing and processing
+- BIN sponsorship
+- risk management
+- support for prepaid, debit, credit, business, and virtual cards
+
+### Why it matters to us
+
+Pomelo is relevant if cards move up the roadmap earlier than planned, or if we eventually want a more specialized card partner than a full-stack BaaS provider.
+
+### Why it is not a top launch pick
+
+For our initial wedge, the main challenge is not card issuance. It is:
+
+- `Pix` payouts
+- worker onboarding
+- employer controls
+- regulated money movement tied to the commission ledger
+
+Pomelo looks better for **later card specialization** than for the first launch dependency.
+
+### Assessment
+
+**Keep warm as a phase 2 or phase 3 card watchlist candidate.**
+
+---
+
+## 7. PagBrasil
+
+### What it is
+
+PagBrasil looks more like a strong local payment and `Pix` specialist than a full BaaS answer.
+
+The official materials we reviewed emphasized **Automatic Pix** and developer-oriented local payment integration.
+
+### Why it matters to us
+
+PagBrasil may become relevant if we later care about:
+
+- recurring collections
+- local payment acceptance
+- payment-event ingestion for employer sales or invoice flows
+
+### Why it is not a primary launch candidate
+
+The current thesis requires more than a payment rail.
+
+We also need:
+
+- regulated account structure
+- onboarding
+- balance management
+- payout orchestration
+- later card optionality
+
+### Assessment
+
+**Adjacency / rail specialist, not the core Brazil launch answer.**
+
+---
+
+## Additional Brazil alternatives to diligence
+
+### Z.ro Bank
+
+What the reviewed public materials clearly show:
+
+- Z.ro describes itself as a **Brazilian digital bank** and crypto exchange
+- its docs homepage highlights **Pix as a Service**, **Zro Gateway**, a **Crypto API**, and a **Payments Gateway API**
+- the PaaS docs show API credentials, test environment URLs, and Pix flows via **Pix key, dynamic QR code, or bank account**
+- the Gateway docs show a useful control pattern for **whitelisting deposit and withdrawal accounts**, with BACEN-related constraints around the number of linked accounts
+
+Why it matters:
+
+- Z.ro is worth considering if we want a more tightly controlled **`Pix`-first wallet / gateway / external-account cash-out** setup
+- the withdrawal-account controls are especially relevant to fraud and beneficiary-governance questions
+
+Main gap versus the top one-provider candidates:
+
+- public evidence is much stronger on `Pix`, gateway, and payments infrastructure than on broad PF/PJ onboarding, employer workflow tooling, and later card depth
+
+### FitBank
+
+What the reviewed public materials clearly show:
+
+- FitBank describes `Fit$ Cash` as a comprehensive financial-services API platform
+- the docs explicitly mention **PIX**, boleto collection, utilities and taxes payments, online balance and statement, **digital onboarding**, and **prepaid card** in a white-label experience
+- the PIX docs state that **FitBank is a direct participant with PIX**
+
+Why it matters:
+
+- FitBank is the strongest newly added **all-round alternative** to the original one-provider set
+- it deserves real diligence if pricing, implementation speed, or commercial fit from the top four is weak
+
+### Zoop
+
+What the reviewed public materials clearly show:
+
+- Zoop's banking docs cover **digital accounts**, **PIX**, **P2P transfers**, **TED**, webhooks, and both **physical and virtual cards**
+- Zoop's Pix product page emphasizes **automatic split of payments** and payment flows embedded in branded journeys
+
+Why it matters:
+
+- Zoop becomes more interesting if employer cash flows, receivables, and split logic are central to the design-partner use case
+- it may be especially relevant if commission creation is tightly linked to marketplace-like payment flows
+
+Main gap for our thesis:
+
+- the public story is more payments / commerce / split-led than employer-funded commission-infrastructure-led
+
+### Transfeera
+
+What the reviewed public materials clearly show:
+
+- Transfeera positions itself as an **authorized payment institution** with API and platform support for **Pix** and **boleto**
+- the public materials reference **sandbox**, **subaccounts**, **multicontas**, **payment split**, batch payments, and a **Pix infraction panel**
+- it publishes availability and transaction-volume metrics and seems especially strong in finance-ops execution
+
+Why it matters:
+
+- Transfeera is a serious **payout and collections specialist** if we want strong finance-ops tooling without making it the full BaaS core
+
+Main gap for our thesis:
+
+- it is not the obvious choice if we also want account creation, card issuance, and broader embedded-banking behavior in the same stack
+
+---
+
+## Recommended stack options for Brazil
+
+## Option A: one-provider comparison wave
+
+Choose from the main one-provider set:
+
+- **Dock**
+- **QI Tech**
+- **Bankly**
+- **Celcoin**
+
+Keep **FitBank** as the strongest additional all-round alternative.
+
+### Why this is attractive
+
+- fastest route to market
+- fewer responsibility boundaries
+- simpler operations during pilot stage
+- easier partner management for a small team
+
+### Best fit when
+
+- we want to prove employer demand quickly
+- we do not yet need deep custom infrastructure decisions
+- we want `Pix` first and cards later
+
+### Current recommendation inside this option
+
+- **Dock** if we want the strongest visible full-stack breadth
+- **Bankly** if we want a very clean bank-licensed and direct-`Pix` story
+- **QI Tech** if we want a strong regulated/API-first middle ground
+- **Celcoin** if we want a stronger modularity bridge toward a later split-stack path
+- **FitBank** as the next alternative if commercial fit or implementation speed is better
+
+---
+
+## Option B: configurable split stack
+
+**Pismo + Celcoin**
+
+- Pismo as core platform for accounts, events, cards, and `Pix` logic
+- Celcoin as the licensed BaaS layer
+
+### Why this is attractive
+
+- potentially better control over architecture
+- strong developer depth
+- cleaner path if we want a highly programmable core
+- explicit compatibility signal because Pismo names Celcoin as a BaaS partner
+
+### Main risk
+
+- more implementation complexity
+- two commercial relationships
+- possible ambiguity around support ownership and operational accountability
+
+### Best fit when
+
+- we already know we want a more custom platform architecture
+- we have enough product clarity to justify higher integration overhead
+
+---
+
+## Option C: narrower `Pix`-first pilot
+
+**Z.ro Bank or Transfeera** for a limited-scope pilot, if:
+
+- the employer-funded use case is mostly external `Pix` cash-out
+- we are not launching cards in v1
+- we do not need a rich stored-balance product on day one
+
+### Why this is attractive
+
+- can be useful for a tightly scoped design-partner pilot
+- keeps focus on the strongest immediate user promise: fast `Pix` access to earned commissions
+
+### Main risk
+
+- risks under-building the broader account, onboarding, and balance-management layer we will eventually need
+
+---
+
+## Option D: one-provider launch + specialist later
+
+**Dock or QI Tech or Bankly or Celcoin or FitBank now** + **Pomelo later if needed**
+
+### Why this is attractive
+
+- keeps the launch simple
+- preserves optionality if we later want a more differentiated card program
+
+### Main risk
+
+- later rework or multi-vendor complexity
+
+---
+
+## Recommended outreach order
+
+### Priority 1: one-provider comparison wave
+
+- **Dock**
+- **QI Tech**
+- **Bankly**
+- **Celcoin**
+
+Goal:
+
+- compare the strongest regulated one-provider launch paths
+- understand pricing, pilot minimums, timeline, and onboarding complexity
+
+### Priority 2: architecture and alternatives
+
+- **Pismo**
+- **FitBank**
+- **Z.ro Bank**
+
+Goal:
+
+- evaluate whether the extra flexibility of a split stack is worth the added complexity
+- compare serious alternatives if the top one-provider set is too expensive, too slow, or too opinionated
+
+### Priority 3: specialists and adjacencies
+
+- **Zoop**
+- **Transfeera**
+- **Pomelo**
+- **PagBrasil**
+
+Goal:
+
+- keep optionality for payment-split use cases, payout-ops tooling, specialized cards, or local collection workflows
+
+---
+
+## Questions to ask every Brazil partner
+
+1. Can you support an **employer-funded commission access** product rather than a consumer-first banking app?
+2. What account structures do you support: named worker accounts, virtual accounts, pooled balance structures, or another model?
+3. Can workers receive `Pix` payouts to an **external key** without using a full bank-account UX from day one?
+4. What KYC/KYB steps are mandatory before first payout?
+5. What webhooks and event streams are available for:
+ - account changes
+ - `Pix` status changes
+ - failures
+ - reversals
+ - fraud or infraction cases
+6. How do you handle `Pix` refunds, infractions, MED-related flows, and suspicious activity?
+7. Can employer approval workflows, reserve rules, and payout limits be enforced programmatically?
+8. How do reconciliation exports and statements work for finance teams?
+9. Can we start with `Pix` and add cards later without changing the core regulated setup?
+10. What are the commercial minimums, implementation fees, and expected pilot timeline?
+11. Do you support both PF and PJ onboarding natively?
+12. What support model exists for incidents on nights, weekends, and holidays?
+
+---
+
+## What a good Brazil partner outcome looks like
+
+A strong Brazil partner should let us support this operational sequence:
+
+1. ingest a payment or validated sale event
+2. create a commission entry in our own ledger
+3. apply employer rules and reserve logic
+4. mark an eligible amount as available
+5. send a `Pix` payout on demand to the worker
+6. handle failures, infractions, or clawbacks without breaking the audit trail
+7. add stored balance and cards later if economics and retention justify them
+
+If a partner is great at cards but weak at steps 4 through 6, it is not the right first partner.
+
+---
+
+## Recommended next steps
+
+### Commercial
+
+Run a first comparison wave across **Dock, QI Tech, Bankly, and Celcoin**.
+
+Keep **FitBank** and **Z.ro Bank** as active alternates if the main one-provider set is too expensive, too slow, or too rigid for an early pilot.
+
+Use the same briefing memo for each:
+
+- employer is the buyer
+- worker is the beneficiary
+- `Pix` payout is the launch wedge
+- our own commission ledger remains the source of truth
+- stored balance and cards are later features
+- direct custody is not the launch model
+
+### Technical
+
+Prepare a diligence worksheet covering:
+
+- account model
+- `Pix` in and out coverage
+- PF/PJ onboarding
+- webhook coverage
+- exception handling
+- reporting
+- sandbox quality
+- card readiness
+- implementation timeline
+
+### Architecture
+
+In parallel, hold one architecture session on **Pismo + Celcoin** specifically to answer:
+
+- what extra flexibility do we gain?
+- what extra integration burden do we accept?
+- which responsibilities sit with which party?
+
+### Legal and compliance
+
+Map with counsel:
+
+- employer vs worker money-flow roles
+- whether balances are treated as payment-account balances, instructions, or another claim structure under the partner setup
+- labor-law treatment of commission availability and deductions
+- who owns customer support and fraud handling under the chosen partner model
+
+---
+
+## Evidence reviewed
+
+### Official and primary materials
+
+- Pismo BaaS docs: https://developers.pismo.io/pismo-docs/docs/banking-as-a-service
+- Pismo `Pix` docs: https://developers.pismo.io/pismo-docs/docs/pix-instant-payments
+- Pismo cards docs: https://developers.pismo.io/pismo-docs/docs/cards-overview-1
+- Dock white-label digital banking: https://dock.tech/en/solution/white-label-digital-banking-platform/
+- Dock white-label cards: https://dock.tech/en/solution/white-label-cards/
+- Dock `Pix` overview: https://dock.tech/solucoes-pix/
+- QI Tech BaaS: https://qitech.com.br/en/baas/
+- QI Tech indirect `Pix`: https://conteudo.qitech.com.br/pix-indireto/
+- Bankly BaaS: https://www.bankly.com.br/en
+- Celcoin BaaS docs: https://developers.celcoin.com.br/docs/sobre-o-baas
+- Celcoin BaaS product page: https://www.celcoin.com.br/solucoes/banking-as-a-service/
+- Celcoin card product page: https://www.celcoin.com.br/cel_card
+- Celcoin card issuance docs: https://developers.celcoin.com.br/docs/emiss%C3%A3o-de-cart%C3%B5es
+- Z.ro Bank docs overview: https://docs.zrobank.io/overview/introduction
+- Z.ro Bank PaaS docs: https://docs.zrobank.io/paas/api-overview/introduction
+- Z.ro Bank Gateway docs: https://docs.zrobank.io/gateway/api-overview/how-to-use
+- FitBank developer docs: https://dev.fitbank.com.br/
+- FitBank PIX intro: https://dev.fitbank.com.br/docs/1-introdu%C3%A7%C3%A3o
+- Zoop Pix product page: https://zoop.com.br/pix/
+- Zoop banking docs: https://docs.zoop.com.br/docs/
+- Transfeera API payments: https://transfeera.com/solucoes/api-de-pagamentos/
+- Transfeera Pix solution: https://transfeera.com/solucoes/pague-receba-pix/
+
+### Supporting watchlist and adjacency sources
+
+- Pomelo issuing and processing: https://pomelo.la/latam/cards/
+- PagBrasil Automatic Pix integration guide: https://www.pagbrasil.com/blog/pix/pagbrasils-automatic-pix-integration-guide-for-developers/
+
+---
+
+## Bottom line
+
+For Brazil, the key decision is not just **which partner is good**.
+
+It is **which architecture path and launch scope we want**.
+
+Current recommendation:
+
+- **Run first-wave commercial diligence with Dock, QI Tech, Bankly, and Celcoin** as the strongest one-provider launch set
+- **Keep FitBank and Z.ro Bank in the active alternative set**
+- **Evaluate Pismo + Celcoin in parallel** as the strongest split-stack architecture path
+- **Use Zoop, Transfeera, Pomelo, and PagBrasil as specialists or adjacencies**, not default launch anchors
+
+That approach keeps the launch aligned with the core thesis:
+
+`commission infrastructure first, instant Pix access second, cards later`
diff --git a/docs/brazil-market.md b/docs/countries/brazil.md
similarity index 100%
rename from docs/brazil-market.md
rename to docs/countries/brazil.md
diff --git a/docs/countries/switzerland-partners.md b/docs/countries/switzerland-partners.md
new file mode 100644
index 0000000..b827347
--- /dev/null
+++ b/docs/countries/switzerland-partners.md
@@ -0,0 +1,728 @@
+# Switzerland partner report
+
+This report expands the initial Switzerland shortlist into a more practical partner view for our commission infrastructure thesis.
+
+The goal is not to find a generic fintech vendor. The goal is to identify which Swiss partners could realistically support:
+
+- a regulated launch structure without direct custody
+- employer and worker onboarding
+- auditable money movement tied to commission events
+- controlled payouts to linked bank destinations
+- a later move into stored balance and card-based retention tools
+
+## Executive summary
+
+### Correction to the original framing
+
+The earlier version of this report leaned too quickly toward a single company for each infrastructure function.
+
+A better Switzerland view is a **layered comparison set**, not a one-vendor-per-layer assumption.
+
+### Regulated account and payout cluster
+
+These are the most relevant candidates for the **regulated money layer**:
+
+- **HBL Solutions / Hypothekarbank Lenzburg**
+- **Yapeal Embedded**
+- **InCore Bank**
+
+HBL still has the strongest public-evidence fit today, but Yapeal and InCore should be in the core diligence set rather than treated as side notes.
+
+### Connectivity and orchestration cluster
+
+These are the most relevant candidates for **bank connectivity, payment submission, or orchestration across providers**:
+
+- **SIX b.Link**
+- **Swisscom**
+- **additiv**
+
+These should be viewed as enabling layers, not automatic substitutes for the regulated bank partner.
+
+### Card and employee spend cluster
+
+These are the most relevant candidates for a later **employee card / spend / retention** layer:
+
+- **Yapeal**
+- **HBL**
+- **additiv + regulated issuer setup**
+
+### Adjacency watchlist
+
+These are worth tracking, but should not anchor the first Swiss build:
+
+- **Swissquote** for treasury, corporate banking, and institutional adjacency
+- **Nuvei** for broader payments and payout orchestration adjacency
+
+### Main conclusion
+
+For Switzerland, the right move is to compare a **cluster of viable partners per layer**:
+
+1. compare **HBL, Yapeal, and InCore** for the regulated account and payout layer
+2. compare **SIX, Swisscom, and additiv** only if connectivity or orchestration complexity appears early
+3. keep **Swissquote** and **Nuvei** as adjacency/watchlist rather than first-wave launch dependencies
+
+That is more consistent with the thesis in `docs/countries/switzerland.md` and avoids over-committing to one provider too early.
+
+---
+
+## What our product needs from a Swiss partner
+
+### Must-have at launch
+
+1. **Regulated money movement**
+ - We should launch under a licensed partner structure rather than taking direct custody.
+ - The partner must be comfortable supporting an employer-operated payout workflow and employee verification.
+
+2. **Employer and worker onboarding**
+ - Employer KYB, worker KYC, sanctions/AML controls, and operational monitoring need to be workable from day one.
+
+3. **API-first payout operations**
+ - We need APIs and webhooks that can support:
+ - commission ledger updates
+ - balance state changes
+ - payout creation
+ - payout status tracking
+ - reversals or manual adjustments where allowed
+
+4. **Bank-based payout support**
+ - Switzerland should be approached conservatively.
+ - We should not assume Brazil-style always-on bank-agnostic instant payouts from day one.
+ - A strong Swiss launch may still be compelling if payouts are fast, auditable, and predictable.
+
+5. **Support for internal controls**
+ - Employer approval rules
+ - payout thresholds
+ - holdbacks and reserves
+ - audit trails
+ - separation of employer funds and employee-visible balances
+
+### Important, but can come later
+
+1. **Stored balance behavior**
+2. **Debit/prepaid card issuance**
+3. **Wallet or limited-acceptance spend controls**
+4. **Richer employer analytics and benchmark reporting**
+
+### Not worth over-optimizing for yet
+
+1. credit products
+2. consumer-neobank positioning
+3. standalone card programs without a solid payout and ledger core
+
+---
+
+## Switzerland market reality for partner selection
+
+Compared with Brazil, Switzerland appears to have a narrower pool of obvious end-to-end fintech infrastructure partners for this use case.
+
+That matters because it changes how we should think about the stack.
+
+### What seems most likely
+
+- the launch partner will probably be a **bank-led BaaS provider**, not just a fintech API layer
+- open-finance connectivity may sit in a **separate layer** from custody and payout execution
+- the card program may also sit in a **separate layer** from the initial payout product
+
+### What that implies for us
+
+The cleanest Swiss setup is likely one of these:
+
+1. **Single regulated-bank launch**
+ - one partner covers onboarding, accounts, payouts, and possibly cards later
+
+2. **Bank + card specialist**
+ - one bank-led partner for custody and payouts
+ - one card-led partner later for employee spend and retention
+
+3. **Bank + open-finance or orchestration layer**
+ - one bank-led partner for regulated money movement
+ - one enabling layer for bank connectivity, payment initiation, or multi-provider orchestration
+
+---
+
+## Evaluation criteria
+
+We should judge Swiss partners against the same decision framework, not just brand familiarity.
+
+| Criterion | Why it matters for us |
+| --- | --- |
+| Regulatory standing | We want a licensed-partner structure rather than direct custody |
+| Account and payout support | The launch wedge depends on controlled disbursement, not just payment acceptance |
+| API maturity | We need a programmable workflow, not manual ops hidden behind a sales deck |
+| Onboarding and compliance tooling | Employer KYB and worker KYC can become the real bottleneck |
+| Card readiness | Important later, but not the deciding factor for v1 |
+| Fit with commission workflow | The partner must support approvals, reversals, reserves, and traceability |
+| Time-to-market risk | Small teams need partners that can actually get a pilot live |
+
+---
+
+## Layered partner map
+
+| Infrastructure layer | Stronger current options | Alternative / adjacency options | How to think about it |
+| --- | --- | --- | --- |
+| Regulated account + payout core | **HBL**, **Yapeal**, **InCore Bank** | Swissquote | This is the real Swiss launch decision layer |
+| Connectivity + payment submission | **SIX b.Link**, **Swisscom** | Swissquote | Useful if employers bank elsewhere and we need external-bank workflows |
+| Embedded-banking orchestration | **additiv**, Swisscom | SIX | Useful if we combine multiple providers rather than relying on one bank stack |
+| Employee card / spend layer | **Yapeal**, HBL | additiv + issuer setup | Important later, not first |
+| Global payments adjacency | Nuvei | Swissquote | More relevant for later expansion than launch |
+
+---
+
+## Public-evidence scorecards
+
+**Legend:** `High` = strong fit from reviewed official materials, `Medium` = partial fit or important gaps still unclear, `Low` = weak public evidence for this use case.
+
+### Regulated account and payout layer
+
+| Partner | Regulatory anchor | Employer / worker onboarding fit | Account / payout fit | API / programmability | Card path | Current priority |
+| --- | --- | --- | --- | --- | --- | --- |
+| **HBL** | High | High | High | High | Medium | **Priority 1** |
+| **Yapeal** | Medium | Medium | Medium | Medium | High | **Priority 1/2** |
+| **InCore Bank** | High | Medium | Medium | Low | Low | **Priority 2** |
+| **Swissquote** | Medium | Medium | Low-Medium | Low | Low | Watchlist |
+
+### Connectivity and orchestration layer
+
+| Partner | Bank connectivity | Payment submission / workflow | Orchestration depth | Embedded-finance fit | Current priority |
+| --- | --- | --- | --- | --- | --- |
+| **SIX b.Link** | High | High | Medium | Medium | **Priority 2** |
+| **Swisscom** | High | Medium | High | Medium | **Priority 2** |
+| **additiv** | Medium | Medium | High | High | **Priority 2** |
+| **Swissquote** | Low-Medium | Low-Medium | Low | Low-Medium | Watchlist |
+
+### Card and employee spend layer
+
+| Partner | Issuing evidence | Workforce / employee use-case fit | Spend-control fit | Need for extra regulated layer | Current priority |
+| --- | --- | --- | --- | --- | --- |
+| **Yapeal** | High | High | High | Medium | **Priority 1/2** |
+| **HBL** | Medium | Medium | Medium | Low | **Priority 2** |
+| **additiv + issuer setup** | Medium | Medium | Medium | High | Watchlist |
+
+---
+
+## Shortlist at a glance
+
+| Partner | Type | Strongest role in our stack | Public-evidence launch fit | Public-evidence later fit | Overall priority |
+| --- | --- | --- | --- | --- | --- |
+| **HBL Solutions / Hypothekarbank Lenzburg** | Regulated bank-backed BaaS | Regulated Swiss banking and payout core | **High** | High | **Priority 1** |
+| **Yapeal Embedded** | Embedded finance / cards-as-a-service | Card layer and alternative regulated-partner path | Medium | **High** | **Priority 1/2** |
+| **InCore Bank** | Swiss B2B transaction bank | Alternative regulated bank-led core | Medium | Low-Medium | Priority 2 |
+| **SIX b.Link** | Open-finance infrastructure | Bank connectivity and payment submission | Medium-Low | Medium | Priority 2 |
+| **Swisscom** | Open-finance / managed banking integration | Middleware and ecosystem integration | Medium-Low | Medium | Priority 2 |
+| **additiv** | Finance-as-a-service orchestration platform | Orchestration layer across regulated providers | Low as standalone regulated core | Medium | Priority 2 |
+| **Swissquote** | Corporate / institutional banking and treasury | Treasury, banking, and institutional adjacency | Low-Medium | Low-Medium | Watchlist |
+| **Nuvei** | Payments and payout infrastructure | Global payments adjacency | Low | Medium | Watchlist |
+
+---
+
+## Detailed partner assessments
+
+## 1. HBL Solutions / Hypothekarbank Lenzburg
+
+### What it is
+
+HBL Solutions is the BaaS and embedded-finance offering backed by **Hypothekarbank Lenzburg AG**.
+
+Its official materials are the clearest Swiss evidence we found of a bank-led partner that could support a regulated commission payout product.
+
+### What the official materials clearly show
+
+HBL states that:
+
+- it is backed by Hypothekarbank Lenzburg as a **regulated Swiss bank**
+- it provides access to its **banking license** for partner products
+- it has an onboarding tool with **over 160,000 account openings**
+- its REST API has **more than 200 endpoints**
+- it supports areas including **customer onboarding, cards, accounts, payments, and pensions**
+- it offers a **sandbox** for testing
+- partner funds can be available **within seconds** when payments move inside the HBL setup, while transfers to third-party banks may take longer
+
+### Why it fits our thesis
+
+This is very close to what we need for Switzerland:
+
+- a regulated institution that can sit behind the initial product
+- programmable banking features, not just consulting
+- onboarding and compliance already built into the stack
+- account and payment primitives that look adaptable to our commission ledger workflow
+
+It also aligns with the conservative Swiss positioning in `docs/countries/switzerland.md`:
+
+- employer control
+- auditability
+- bank-based payouts
+- no need to lead with consumer credit or wallet hype
+
+### Best role in our stack
+
+**Primary launch partner** for:
+
+- regulated account structure
+- employer and worker onboarding
+- payout execution
+- account and transaction data
+- support for later card expansion if the commercial model works
+
+### What we still need to validate
+
+1. Can HBL support a structure where we maintain our own internal commission ledger while they maintain the regulated money layer?
+2. Can they support **employer master account + worker-level views or sub-accounts**, or do they expect a different account model?
+3. What does worker KYC look like in a B2B2C employer-sponsored flow?
+4. Can payout approvals, holdbacks, and reserve logic be implemented cleanly?
+5. Are payout timelines acceptable when moving to **third-party Swiss banks**?
+6. What card setup is actually available for a later employee card program?
+7. What are the commercial minimums, implementation time, and support model?
+
+### Assessment
+
+**Strongest Swiss first-call candidate.**
+
+If we were prioritizing outreach today, HBL would be the obvious first meeting.
+
+---
+
+## 2. Yapeal Embedded
+
+### What it is
+
+Yapeal positions itself around embedded finance and cards-as-a-service in Switzerland.
+
+Its public materials are especially interesting because they are not framed only around generic consumer banking. They point to specific embedded use cases.
+
+### What the official materials clearly show
+
+Public Yapeal materials indicate:
+
+- it offers **Cards-as-a-Service** for banks and fintech companies
+- it offers **embedded finance for digital platforms**
+- it highlights branded cards and **limited-acceptance cards**
+- it explicitly mentions use cases such as **employee benefits**, **mobility**, and targeted spending categories
+- one public testimonial references the ability to provide **employee credit cards** quickly and easily
+
+### Why it fits our thesis
+
+Yapeal maps especially well to our **later roadmap**:
+
+- employee card access to stored balances
+- employer-controlled spend programs
+- targeted or limited-use card products
+- retention and platform utility beyond bank payouts alone
+
+That makes it relevant even if it is not the first partner we sign.
+
+### Best role in our stack
+
+**Phase 2 or phase 3 partner** for:
+
+- prepaid/debit/card-led access to balances
+- employee spend controls
+- employer-branded or platform-branded card programs
+- specialized spend use cases tied to commissions, benefits, or mobility
+
+### Main uncertainty
+
+The accessible public materials are clearer on the **card proposition** than on the full **banking and payout proposition**.
+
+We still need to know:
+
+1. whether Yapeal can be the main regulated partner for employer-funded payout flows
+2. whether it supports the account architecture we need for commission balances
+3. whether it is best used as a standalone partner or as a specialist card layer on top of a bank-led core
+4. whether payout and reconciliation tooling is as strong as its embedded card story
+
+### Assessment
+
+**Most interesting Swiss card-led option, but not yet the default primary launch partner.**
+
+If cards remain intentionally later, Yapeal should be a second-wave diligence item rather than the very first dependency.
+
+---
+
+## 3. SIX b.Link
+
+### What it is
+
+SIX b.Link is open-finance infrastructure for the Swiss market.
+
+It matters because our product will eventually need reliable access to account information and payment submission workflows, especially if employers keep their main operating accounts at different banks.
+
+### What the official materials clearly show
+
+SIX describes b.Link as:
+
+- the Swiss open-banking platform connecting **banks and fintechs** through standardized APIs
+- a platform that supports **payment submission** from third-party applications into customer e-banking
+- a way to retrieve payment status and connect related services such as **account information**
+- an implementation of common Swiss API standards
+
+### Why it matters to us
+
+This is useful for two parts of our product:
+
+1. **Reconciliation and visibility**
+ - We may want account data from employer bank accounts for commission creation and payout confirmation.
+
+2. **Payment initiation / submission**
+ - We may want to let employers approve or submit payouts from within our workflow rather than leaving the platform.
+
+### Where it does not fit well
+
+b.Link does **not** look like the primary answer for:
+
+- regulated custody
+- employer and worker onboarding
+- issuing employee cards
+- running the full B2B2C payout stack on its own
+
+### Best role in our stack
+
+**Open-finance connectivity layer** if we later need:
+
+- multi-bank employer account connectivity
+- account information feeds
+- payment submission flows into external bank channels
+
+### Assessment
+
+**Important ecosystem layer, not the primary launch bank.**
+
+We should understand it, but probably not make it the first integration unless bank-data fragmentation becomes central to the pilot.
+
+---
+
+## 4. Swisscom
+
+### What it is
+
+Swisscom appears to operate at the infrastructure and managed-services layer of Swiss open finance.
+
+### What the official materials clearly show
+
+Swisscom describes:
+
+- an **Open Business Hub** as a central access point to API ecosystems for financial services
+- several hundred interfaces and support for standards such as **Common API** and **OpenWealth API**
+- a **Managed Finance Ecosystem** that can support banking operations and connect third-party solutions
+- a SaaS-style operating model intended to reduce integration and maintenance burden
+
+### Why it matters to us
+
+Swisscom may become relevant if our Swiss stack needs:
+
+- middleware between multiple banking and data systems
+- standardized ecosystem integration
+- managed banking infrastructure around a partner bank setup
+- enterprise-grade interface management
+
+### Main concern
+
+Swisscom looks more like a **banking-enablement and integration layer** than the clean regulated partner we want for an early wedge product.
+
+For an early-stage company, there is a real risk that this becomes too broad or too enterprise-heavy before we have proved the core workflow.
+
+### Best role in our stack
+
+**Secondary infrastructure layer** if we later need more complex bank and ecosystem integration.
+
+### Assessment
+
+Useful to understand, but probably **not a first-priority launch dependency**.
+
+---
+
+## 5. Nuvei
+
+### What it is
+
+Nuvei appears more naturally as a payments and payout infrastructure partner than as the core Swiss BaaS provider.
+
+The search evidence we reviewed points to Swiss support for:
+
+- CHF
+- pay-ins
+- payouts
+- refunds
+- recurring payments
+- chargeback handling
+
+### Where it may help
+
+Nuvei could matter if we later need:
+
+- merchant payment acceptance alongside payout operations
+- broader multi-country payment orchestration
+- payout rails beyond a purely Swiss bank-led setup
+- issuing adjacency at a global level
+
+### Why it is not the lead Swiss recommendation
+
+For our current thesis, Nuvei looks less directly aligned with:
+
+- employer/worker onboarding
+- the regulated-account layer
+- B2B2C commission ledger integration
+- a Swiss employer workflow product anchored around a local bank partner
+
+### Assessment
+
+**Watchlist / adjacent partner**, not the top Swiss launch candidate.
+
+---
+
+## Additional Swiss alternatives to diligence
+
+### InCore Bank
+
+What the reviewed public materials clearly show:
+
+- InCore describes itself as a **Swiss B2B transaction bank** for banks, financial intermediaries, and companies
+- it emphasizes **banking and technology from one hand**
+- its positioning is clearly B2B and infrastructure-oriented rather than consumer-led
+
+Why it matters:
+
+- it is a credible **alternative regulated bank-led core** for a Swiss launch
+- it looks particularly relevant if we want a more transaction-bank profile and are comfortable doing more diligence on product specifics
+
+Main gap versus HBL:
+
+- the public materials we reviewed are much less explicit on embedded-finance APIs, onboarding tooling, sandbox access, and employer/worker payout flows
+
+### additiv
+
+What the reviewed public materials clearly show:
+
+- additiv positions `addBanking` as a platform that can orchestrate **onboarding, accounts, payments, and compliance**
+- it supports **white-label, managed-service, and embedded** operating models
+- it can source services through an **open ecosystem of regulated providers** rather than replacing the underlying regulated stack
+
+Why it matters:
+
+- additiv is a serious **orchestration-layer alternative** if we want flexibility across banks or providers
+- it is particularly relevant if the Swiss stack becomes multi-provider rather than single-bank
+
+Main gap versus HBL / Yapeal:
+
+- additiv is not itself the obvious regulated balance holder for launch, so it should be paired with a bank or issuer rather than treated as the sole Swiss launch partner
+
+### Swissquote
+
+What the reviewed public materials clearly show:
+
+- Swissquote offers **multi-currency business accounts**, transfers, treasury tools, and institutional partner services
+- its institutional materials describe **segregated client and corporate accounts**, reporting, and institutional infrastructure
+
+Why it matters:
+
+- Swissquote could matter as a **treasury and banking adjacency** for employer-side banking, multi-currency handling, or institutional partnership discussions
+
+Main gap for our use case:
+
+- public evidence for an employer-funded, worker-beneficiary commission payout stack is weaker than for HBL and less card-specific than Yapeal
+
+---
+
+## Recommended stack options for Switzerland
+
+## Option A: regulated-bank comparison wave
+
+**HBL or Yapeal or InCore**
+
+Use the first diligence wave to choose the regulated Swiss core after comparing:
+
+- account model
+- worker onboarding model
+- payout speed to external bank accounts
+- reserve and holdback support
+- card optionality
+
+### Why this is attractive
+
+- avoids premature lock-in to one Swiss bank stack
+- reflects the reality that Switzerland has a small but meaningful comparison set
+- gives us a cleaner basis for commercial negotiation
+
+### Main risk
+
+- takes slightly longer than assuming one default winner from the start
+
+---
+
+## Option B: bank-led launch, card-led expansion
+
+**HBL or InCore + Yapeal**
+
+- HBL or InCore for regulated banking and payout operations
+- Yapeal later for cards, spend controls, or employee retention products
+
+### Why this is attractive
+
+- preserves the conservative bank-led launch
+- keeps optionality for a stronger employee card experience later
+- reduces pressure to force cards into v1
+
+### Main risk
+
+- multi-vendor coordination
+- overlap and responsibility boundaries need early clarification
+
+---
+
+## Option C: bank core plus connectivity or orchestration layer
+
+**HBL or InCore + SIX or Swisscom or additiv**
+
+- one bank-led partner for regulated money movement
+- one enabling layer for bank connectivity, payment submission, or multi-provider orchestration
+
+### Why this is attractive
+
+- useful if employers keep their main accounts at multiple Swiss banks
+- useful if reconciliation and treasury visibility across banks becomes a pilot requirement
+
+### Main risk
+
+- probably too much complexity for the very first pilot unless bank fragmentation is already a real blocker
+
+---
+
+## Recommended outreach order
+
+### Priority 1: regulated-layer comparison
+
+- **HBL Solutions / Hypothekarbank Lenzburg**
+- **Yapeal Embedded**
+- **InCore Bank**
+
+Goal of first calls:
+
+- compare regulated account structures
+- compare payout mechanics and payout timing
+- compare B2B2C onboarding assumptions
+- understand card optionality, implementation timelines, and minimums
+
+### Priority 2: enabling layers
+
+- **SIX b.Link**
+- **Swisscom**
+- **additiv**
+
+Goal of first calls:
+
+- decide whether a connectivity or orchestration layer is needed before the pilot or only later
+- identify whether external-bank account information and payment submission are likely blockers
+
+### Watchlist
+
+- **Swissquote**
+- **Nuvei**
+
+Goal:
+
+- keep institutional banking, treasury, and global payments adjacencies warm without making them first-wave dependencies
+
+---
+
+## Questions to ask every Swiss partner
+
+1. Can you support an **employer-funded** payout product where employees are beneficiaries but not the buyer?
+2. What account models do you support: pooled account, named individual accounts, virtual sub-accounts, or another structure?
+3. Can we maintain our own commission ledger while using your regulated money-movement layer?
+4. What worker KYC level is required before a user can receive payouts?
+5. Can payouts be sent to an external Swiss bank account or IBAN controlled by the worker?
+6. What are the expected settlement speeds for same-bank and third-party-bank payouts?
+7. How are reversals, disputes, freezes, and suspicious-activity reviews handled?
+8. Can employer approval workflows, reserve rules, and payout limits be encoded in the API workflow?
+9. What webhooks, event streams, reconciliation exports, and reporting tools are available?
+10. What are the commercial minimums, onboarding timelines, and implementation support model?
+11. If we later add cards, can you support prepaid/debit issuance and wallet tokenization?
+12. What data residency and operational support commitments do you provide?
+
+---
+
+## What a good Swiss partner outcome looks like
+
+A strong Swiss partner decision should let us build this sequence:
+
+1. validate payment or invoice event
+2. create commission entry in our own ledger
+3. mark a portion as available under employer policy
+4. trigger payout through a regulated partner
+5. give the employer and worker a clear audit trail
+6. add stored-balance or card behavior only after the payout workflow is working reliably
+
+If a partner is strong on cards but weak on the above sequence, it is not the right first partner.
+
+---
+
+## Recommended next steps
+
+### Commercial
+
+- Open conversations with **HBL, Yapeal, and InCore** in the first wave.
+- Run a second architecture wave with **SIX, Swisscom, and additiv** only if design partners need multi-bank connectivity or orchestration.
+- Prepare a short partner memo describing:
+ - employer buyer
+ - worker beneficiary
+ - payout-to-bank first model
+ - later optional card layer
+ - no direct custody at launch
+
+### Product and technical
+
+Create a partner diligence worksheet covering:
+
+- account model
+- KYC/KYB flow
+- payout methods and timing
+- webhook/event coverage
+- reversal and holdback support
+- reporting and reconciliation
+- card optionality
+- sandbox quality
+- pricing and minimums
+
+### Legal and compliance
+
+Map with counsel:
+
+- which party is merchant/employer/platform in the flow
+- whether employee balances are treated as claims, stored value, or simple payout instructions under the chosen structure
+- who owns AML monitoring, suspicious-activity handling, and customer support obligations
+
+---
+
+## Evidence reviewed
+
+### Official and primary materials
+
+- HBL Solutions Banking-as-a-Service: https://www.hblsolutions.ch/en/
+- Yapeal embedded finance for digital platforms: https://yapeal.ch/en/yapeal-embedded/solutions/embedded-finance-for-digital-platforms/
+- Yapeal cards-as-a-service: https://yapeal.ch/en/yapeal-embedded/solutions/cards-as-a-service-for-banks/
+- Yapeal homepage / client examples: https://yapeal.ch/en/
+- InCore Bank: https://www.incorebank.ch/en/
+- SIX b.Link payment submission: https://blink.six-group.com/en/services/payment-submission
+- SIX b.Link docs: https://docs.blink.six-group.com/docs/whats-blink/
+- Swisscom Open Business Hub: https://www.swisscom.ch/en/business/enterprise/offer/banking/open-finance-ecosystem/open-business-hub.html
+- Swisscom Managed Finance Ecosystem: https://www.swisscom.ch/en/business/enterprise/offer/banking/managed-finance-ecosystem.html
+- additiv addBanking: https://www.additiv.com/addbanking
+- additiv platform: https://www.additiv.com/platform/
+- Swissquote companies: https://www.swissquote.com/en/institutional/clients/companies
+- Swissquote banks / institutional partners: https://www.swissquote.com/en/institutional/clients/banks
+
+### Supporting source used for adjacency only
+
+- Nuvei Swiss payments overview: https://www.nuvei.com/apm/swiss-payments
+
+---
+
+## Bottom line
+
+For Switzerland, we should optimize for **regulated bank-backed execution first**, but without forcing the infrastructure map into one obvious company per role.
+
+That means the current recommendation is:
+
+- **Run first-wave diligence across HBL, Yapeal, and InCore for the regulated layer**
+- **Treat SIX, Swisscom, and additiv as optional enabling layers rather than default launch dependencies**
+- **Keep Swissquote and Nuvei as adjacency watchlist names**
+- **Avoid designing the Swiss launch around cards before the payout workflow is proven**
diff --git a/docs/countries/switzerland.md b/docs/countries/switzerland.md
new file mode 100644
index 0000000..05c4159
--- /dev/null
+++ b/docs/countries/switzerland.md
@@ -0,0 +1,167 @@
+# Switzerland market note
+
+## Summary
+
+Switzerland is a plausible country dossier for this idea if the company wants to test the product in a high-trust, compliance-heavy market with commission-driven employers.
+
+The product thesis stays the same:
+
+`turn each validated sale into an auditable commission balance, then let employers decide how quickly the eligible portion can be paid out`
+
+The initial product should not be sold as a bank account or a consumer credit product. The stronger thesis is commission infrastructure with fast, controlled payouts and strong employer auditability.
+
+## Why Switzerland matters
+
+- Employers often have high expectations around accuracy, auditability, and operational reliability.
+- Commission-heavy teams exist across insurance, brokerage, recruiting, financial advisory, property-related sales, medical services, and B2B sales organizations.
+- A strong employer workflow product can matter even if the worker-liquidity wedge is less dramatic than in markets with a stronger informal-advance culture.
+- The market can test whether the thesis works in a more compliance-intensive environment.
+- A premium operating product may resonate with Swiss SMB and mid-market buyers if it reduces errors and admin load.
+
+## Local pain that the product solves
+
+### For the employer
+
+- Commission rules often live across spreadsheets, CRM exports, accounting workflows, and payroll handoffs.
+- Month-end reconciliation is slow and error-prone.
+- Finance teams lack a live view of commission liability and pending adjustments.
+- Disputes are harder to resolve when calculation logic and payout history are fragmented.
+
+### For the employee
+
+- Commission visibility often arrives late.
+- There is limited transparency around what has been earned, what is available, and what is still pending.
+- Payout timing can feel opaque even when the employer intends to pay fairly.
+- Faster access to eligible balances may improve trust, even when immediate liquidity is not the only pain point.
+
+## Initial ICP
+
+The best initial targets are Swiss SMB and mid-market employers with commission-heavy teams and clearly attributable payment or invoice events.
+
+Promising segments:
+
+- insurance brokerages and advisory networks
+- staffing and recruiting firms
+- property-related sales organizations
+- clinics, medical services, or elective-care businesses with trackable payment events
+- subscription and field-sales businesses with clear seller attribution
+
+## Value proposition in Switzerland
+
+### For the employer
+
+- automate commission calculation and payout operations
+- reduce spreadsheet dependence and manual reconciliation
+- create a clear audit trail across sales, commissions, payouts, and adjustments
+- improve visibility into commission liability and team performance
+- reduce payout disputes and exception handling
+
+### For the employee
+
+- see earned commissions sooner
+- understand what is available versus still pending
+- receive eligible payouts faster through the linked bank destination
+- track earnings history and payout activity in one place
+
+## Recommended product for Switzerland
+
+### V1
+
+- payment reconciliation through local PSP, banking, or invoice data
+- commission rules engine
+- ledger with states `earned`, `available`, and `settled`
+- balances for employee and employer
+- payout request workflow to linked bank destination
+- basic employer and employee dashboards
+- audit trail by payment event, commission result, payout, and adjustment
+
+### V2
+
+- clearer reserve and holdback rules for reversals
+- analytics for team performance and commission liability
+- alerts and anomaly reporting
+- stored balance behavior if partner structure and economics justify it
+- pilot of employer-backed advances only after the ledger is reliable
+
+### V3
+
+- card or spend product only if local partner economics justify it
+- deeper ERP, CRM, POS, or payroll integrations
+- multi-entity support for larger organizations
+
+## Partners that matter locally
+
+### Financial infrastructure
+
+- regulated bank, BaaS, or payment partner for safeguarded funds, payouts, and compliance
+- payout partner that can support employer and worker money movement without forcing direct custody at launch
+
+### Payment and reconciliation infrastructure
+
+- PSPs, acquirers, billing tools, or invoice-reconciliation partners that can provide reliable payment-event data
+
+### Identity and compliance
+
+- KYC, KYB, AML, and sanctions tooling for employer and employee onboarding
+- legal and compliance advisors with Swiss financial-regulation and labor-workflow experience
+
+### Card issuance
+
+- only later, if the product proves balance retention is worth pursuing
+
+## Regulatory and operating considerations
+
+The product touches several regulated and operational areas and should be mapped carefully.
+
+- start under a licensed partner structure rather than direct custody
+- map the FINMA-related regulatory perimeter and partner responsibilities early
+- understand employer onboarding, AML, and worker verification requirements
+- map how commissions, deductions, payroll timing, and adjustments should be reflected in employer workflows
+- make availability, reversals, and clawback logic explicit to employers and employees
+- keep employer-backed advances as a later feature, not the initial wedge
+
+## Go-to-market in Switzerland
+
+### First move
+
+- win 3 to 5 design partners with strong commission admin pain and clean payment attribution
+- prioritize employers where commission rules are painful but not too custom to support in v1
+- sell to finance, operations, founders, and sales leadership
+
+### Distribution channels
+
+- direct sales to design partners
+- referrals from accounting, payroll, or finance consultants
+- vertical SaaS and payment-partner relationships
+- operator networks or industry groups where commission plans are common
+
+### Initial pitch
+
+- remove spreadsheet commission work
+- improve auditability and payout reliability
+- give teams clearer and faster access to eligible earnings
+- reduce payout disputes and manual exception handling
+
+## Most likely economic model
+
+- employer platform fee
+- fee per processed or reconciled payment event
+- payout fee or bundled payout plan
+- premium analytics tier for larger employers
+- later card or retained-balance economics if the partner model supports them
+
+## Key risks in Switzerland
+
+- smaller domestic market than some larger launch geographies
+- stronger compliance expectations can slow onboarding and iteration
+- local labor and payroll expectations may require careful configuration
+- payout speed expectations may vary by partner and bank behavior
+- employer demand for worker-liquidity features may be weaker than in markets with more visible advance behavior
+
+## Final thesis for Switzerland
+
+The best positioning is not a neobank and not an employee-wallet-first app.
+
+The best positioning is:
+
+`commission operations infrastructure for Swiss employers, with auditable ledgers, bank-based payouts, and strong employer control`
diff --git a/docs/market-memo.md b/docs/market-memo.md
index a4f05e4..fc918ec 100644
--- a/docs/market-memo.md
+++ b/docs/market-memo.md
@@ -2,13 +2,13 @@
## Thesis
-There is a clear product gap between commission software, faster worker payouts, and Brazil-native embedded finance.
+There is a clear product gap between commission software, faster worker payouts, and locally integrated money movement.
-Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a Brazil-first platform built around real-time commission availability.
+Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a location-independent platform built around real-time commission availability and localized country execution.
## The gap in the market
-Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and informal employee advances. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
+Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and ad hoc employee advance requests. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
Existing vendors tend to split into separate categories:
@@ -16,21 +16,20 @@ Existing vendors tend to split into separate categories:
- payout rails and disbursement infrastructure
- commission calculation and analytics software
- employee wallet or card experiences
-- Brazil payment and card infrastructure
+- local payment, banking, and compliance infrastructure
The opportunity is to combine these into a single workflow built around a verified payment event.
## Competitor map
-| Company | What it does well | Missing piece relative to this idea |
+| Company or category | What it does well | Missing piece relative to this idea |
|---|---|---|
| `DailyPay` | Earned wage access, employee liquidity, employer integrations | Not centered on payment-linked commissions or commission-heavy teams |
| `Branch` | Workforce payments, employee app, card, embedded finance | More generic worker finance than commission-specific infrastructure |
-| `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system and Brazil-specific positioning |
+| `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system |
| `Hyperwallet` | Global payout orchestration | Infrastructure layer, not a commission system of record |
| `CaptivateIQ` | Commission calculation, visibility, forecasting | No native money movement or worker access to balances |
-| `Caju` | Brazil employee finance and card experience | Not the source of truth for commission creation and payout logic |
-| `Dock` | Brazil financial infrastructure for accounts, cards, `Pix` | Not a direct competitor; more likely an enabling layer |
+| Local payment and BaaS partners | Country-specific rails, compliance coverage, and movement infrastructure | Usually not the employer-facing commission system of record |
## What is differentiated here
@@ -47,18 +46,6 @@ That positioning changes the product in important ways:
- the employee gets liquidity without relying on informal advances
- the company can monetize software, payment flow, and later retained balances
-## Why Brazil first
-
-Brazil is the more compelling launch market than Switzerland for this specific thesis.
-
-- `Pix` makes instant access behaviorally normal.
-- Informal paycheck advances or `vales` create a visible pain point.
-- Smaller financial institutions and infrastructure partners may be more open to collaboration.
-- Commission-heavy SMB and mid-market businesses are common.
-- The value proposition is concrete and easy to explain.
-
-Switzerland may still matter later, but Brazil provides the clearer wedge, larger behavioral advantage, and stronger infrastructure fit for instant commission access.
-
## Recommended wedge
The initial product should avoid trying to become a broad payroll platform or a credit-led consumer app.
@@ -68,11 +55,36 @@ The recommended wedge is:
- process or reconcile customer payments
- calculate commissions in real time
- make a safe portion of earned commissions available immediately
-- let workers cash out via `Pix`
+- let workers cash out over the relevant local payout rail
- give employers dashboards, controls, and reporting
This creates value for both sides without requiring the company to start as a full lending business.
+## Country strategy
+
+Country-specific launch assumptions should live in `docs/countries/`, not in the core product docs.
+
+The core product should stay constant across markets:
+
+- payment-linked commission creation
+- auditable ledger and balance states
+- employer controls and analytics
+- employee access to eligible balances
+- partner-led custody and regulated money movement
+
+The parts that should vary by country are:
+
+- payout rail and settlement behavior
+- partner stack
+- onboarding, KYC, and KYB workflow
+- regulatory and labor treatment
+- target verticals and go-to-market sequence
+
+Current country dossiers live in:
+
+- `docs/countries/brazil.md`
+- `docs/countries/switzerland.md`
+
## Differentiation versus adjacent players
### Versus `DailyPay` and `Branch`
@@ -89,11 +101,12 @@ This creates value for both sides without requiring the company to start as a fu
### Versus `PayQuicker` and `Hyperwallet`
- own employer workflows and analytics, not just disbursement rails
-- focus on Brazil-native behavior and infrastructure
+- keep the employer-side commission ledger as the system of record
-### Versus `Caju`
+### Versus local infrastructure partners
-- own the commission event and payout logic, not only the employee finance interface
+- use them as enabling rails, not as the full product
+- keep portability by separating partner adapters from the core ledger and workflow logic
## Business model
@@ -118,9 +131,9 @@ The key is to avoid depending on balance-sheet lending to make the model work.
### Target customers
-- Brazil-based SMB and mid-market employers with commission-heavy teams
+- employers in the selected launch country with commission-heavy teams
- businesses where payment events are digital and attributable
-- verticals such as franchise retail, clinics, education, auto, telecom, and other sales-led operations
+- verticals such as franchise retail, clinics, education, agencies, brokerages, recruiting, telecom, and other sales-led operations
### Buyer
@@ -132,16 +145,16 @@ The key is to avoid depending on balance-sheet lending to make the model work.
### Core pitch
- reduce manual commission work
-- reduce informal advances
+- reduce informal advances or exception requests
- help retain and motivate sales staff
- create a trusted real-time view of commission liability and performance
### Distribution channels
- direct sales to design partners
-- vertical SaaS and POS partnerships
-- franchise groups
-- accounting and payroll-adjacent referral channels
+- vertical SaaS and PSP partnerships
+- franchise or operator groups where relevant
+- accounting, payroll, and finance-adjacent referral channels
## Defensibility
@@ -160,9 +173,10 @@ If the company succeeds, defensibility should come from workflow ownership and d
- regulatory boundaries around custody, wage access, and credit
- dependence on a single bank, BaaS, or card partner
- low balance retention if the product offers no reason to keep funds in-platform
+- overfitting the core product to one country instead of keeping local assumptions modular
## Bottom line
This idea is attractive because it sits in the overlap of three proven categories: commission software, worker liquidity, and embedded finance.
-The market does not appear empty, but it still looks fragmented. A Brazil-first product that turns every validated sale into an auditable, instantly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.
+The market does not appear empty, but it still looks fragmented. A location-independent product that turns every validated sale into an auditable, quickly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.
diff --git a/docs/prototype-plan.md b/docs/prototype-plan.md
index 791dc73..1920e2f 100644
--- a/docs/prototype-plan.md
+++ b/docs/prototype-plan.md
@@ -4,7 +4,7 @@
Build the smallest functional prototype that proves the core wedge for this company:
-`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed instantly via Pix`
+`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed quickly through the relevant local payout rail`
This prototype should validate three things at once:
@@ -27,7 +27,7 @@ That means:
## Core hypothesis
-If a Brazil-based employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through `Pix`, then the company will have a strong design-partner wedge.
+If an employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through the relevant local payout rail, then the company will have a strong design-partner wedge.
## Primary prototype users
@@ -52,7 +52,7 @@ Needs to:
- see what has been `earned`
- see what is `available`
- understand what is still pending or held in reserve
-- request a `Pix` cash-out
+- request a payout to a linked bank destination
- trust that the numbers are correct
### Internal ops admin
@@ -134,10 +134,10 @@ Mobile-first web experience that shows:
- current `earned`, `available`, and `settled` balances
- transaction history
- payout history
-- current `Pix` key on file
+- current payout destination on file
- payout request button
-#### 6. `Pix` payout flow
+#### 6. Local payout flow
For the prototype, use partner-led abstractions and manual controls.
@@ -191,19 +191,19 @@ Use one clear happy-path demo story.
### Example
-- employer: aesthetic clinic group in Brazil
+- employer: aesthetic clinic group
- employee: seller named Ana
- rule: 20 percent commission on completed payments
- availability rule: 70 percent of commission becomes immediately `available`; 30 percent stays held until settlement
-- customer payment: `R$1,000`
+- customer payment: `1,000` in local currency
System behavior:
-- payment received: `R$1,000`
-- commission calculated: `R$200 earned`
-- immediate availability: `R$140 available`
-- held amount: `R$60 pending settlement`
-- Ana requests `R$100` `Pix` cash-out
+- payment received: `1,000` in local currency
+- commission calculated: `200 earned`
+- immediate availability: `140 available`
+- held amount: `60 pending settlement`
+- Ana requests a `100` payout to her linked bank destination
- employer dashboard updates liability and payout history
This single scenario should work end to end before adding more complexity.
@@ -231,7 +231,7 @@ This single scenario should work end to end before adding more complexity.
1. employee opens mobile web app
2. employee sees `available` balance
-3. employee requests payout to registered `Pix` key
+3. employee requests payout to the registered bank destination
4. payout request is validated
5. payout is sent through mocked or manual partner adapter
6. ledger records the payout and reduces `available`
@@ -306,7 +306,7 @@ A simple but durable architecture is enough.
Define adapters even if they are mocked.
- `PaymentProviderAdapter`
-- `PixPayoutAdapter`
+- `LocalPayoutAdapter`
- `KycProviderAdapter`
This keeps the prototype aligned with the long-term partner-led model and avoids hard-coding demo logic everywhere.
@@ -372,7 +372,7 @@ The prototype is successful if it can demonstrate all of the following in one co
- an employer can be configured in under 30 minutes
- a payment event generates a commission and updates balances automatically
- an employee understands `earned` versus `available`
-- an employee can request a `Pix` payout from the `available` balance
+- an employee can request a payout from the `available` balance
- a refund or reversal creates a visible adjustment without breaking the ledger story
- an employer can view liability, payouts, and audit history without relying on spreadsheets
@@ -383,7 +383,7 @@ To move faster, these can be manual in the first prototype:
- KYB and KYC review
- employer contract setup
- payment provider onboarding
-- actual `Pix` movement through a partner
+- actual payout movement through a partner
- exception handling and customer support
- settlement reconciliation edge cases
@@ -451,7 +451,7 @@ After this plan, the next useful documents would be:
- a short product requirements doc for the prototype
- wireframes for employer and employee flows
- an event model spec for payments, commissions, payouts, and adjustments
-- a partner-interface spec for mocked `Pix`, KYC, and payment ingestion
+- a partner-interface spec for mocked local payouts, KYC, and payment ingestion
## Bottom line
@@ -459,4 +459,4 @@ The right prototype is not a broad fintech app.
It is a narrow commission infrastructure demo that proves one loop extremely well:
-`payment event -> commission calculation -> earned and available balance -> Pix payout -> employer visibility and audit trail`
+`payment event -> commission calculation -> earned and available balance -> local payout -> employer visibility and audit trail`
diff --git a/docs/year-one-roadmap.md b/docs/year-one-roadmap.md
index 3047859..912013c 100644
--- a/docs/year-one-roadmap.md
+++ b/docs/year-one-roadmap.md
@@ -21,14 +21,14 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
#### Objectives
- validate the first customer segment
-- choose partner model for custody, payouts, and compliance
+- choose the initial market and partner model for custody, payouts, and compliance
- lock the ledger and commission system design
#### Workstreams
- run design-partner interviews with target employers
- map employer commission workflows and exception cases
-- choose payment and banking partner shortlist
+- choose the market-specific payment and banking partner shortlist
- define balance states: `earned`, `available`, `settled`
- define reserve and holdback logic for reversals
- specify onboarding flows for employers and employees
@@ -44,7 +44,7 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
- 5 to 10 serious design partners in pipeline
- clear v1 scope that does not depend on lending
-- chosen path for `Pix` and custody infrastructure
+- chosen path for the local payout rail and custody infrastructure
## Core ledger and instant payout access
@@ -65,7 +65,7 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
- internal ledger
- employee balance with `earned`, `available`, and `settled`
- employer settlement scheduling
-- instant payout access via `Pix` or equivalent instant transfer rail
+- instant payout access via the local instant or fast transfer rail
- employer dashboard with payout and commission views
- employee dashboard with balance and payout history
diff --git a/sessions/session-ses_29db.md b/sessions/session-ses_29db.md
deleted file mode 100644
index e22ca79..0000000
--- a/sessions/session-ses_29db.md
+++ /dev/null
@@ -1,11225 +0,0 @@
-# Z.ro Bank documentation review and required services list
-
-**Session ID:** ses_29db90a57ffeTmuUWkytK6ZXjK
-**Created:** 4/6/2026, 11:11:50 AM
-**Updated:** 4/6/2026, 11:28:14 AM
-
----
-
-## User
-
-I was looking at Z.ro bank at they seem to be able to provide most of the services we need to get started, go over their documentation and tell me exactly what we need. https://zrobank.com/en
-
----
-
-## Assistant (Plan · GPT-5.4 · 20.0s)
-
-_Thinking:_
-
-**Researching documentation options**
-
-The task involves mostly research, and I wonder if we could skip the to-do list if it's manageable. I think using a task explore agent might help to check external sites, but I’m not sure if it can only search codebases. I feel like the general agent could address complex questions and execute multi-step tasks. Since the user wants a documentation review, I’m considering whether we should use webfetch to access the homepage and documentation pages to identify gaps in information.
-
-_Thinking:_
-
-**Reading core documentation**
-
-Since the repo docs are available and relevant, I think it's wise to read through the core documentation to tailor the requirements. I could use multi_tool_use.parallel to read key docs and fetch site pages simultaneously. I need to provide a commentary update before diving into the tasks, indicating I'm reviewing both our docs and the Z.ro pages. It's essential to identify if there are documentation pages for "developers," "open finance," or "banking as a service" on the Z.ro site. Using the browser or webfetch could help navigate and capture links efficiently.
-
-Reviewing our current product requirements alongside Z.ro’s public site and documentation so I can map their offering to the exact launch needs and gaps.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/core-idea.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/core-idea.md
-file
-
-1: # Core Idea
-2:
-3: ## One-line thesis
-4:
-5: A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.
-6:
-7: ## The problem
-8:
-9: ### Employers
-10:
-11: - Commission calculation is often manual, delayed, and hard to audit.
-12: - Sales teams ask for informal advances when payroll cycles lag behind real sales activity.
-13: - Finance teams struggle to forecast commission liability and reconcile payouts.
-14: - Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.
-15:
-16: ### Employees
-17:
-18: - A sale can happen today, but the commission may not be usable for days or weeks.
-19: - Early access to money often depends on asking for an informal advance.
-20: - There is rarely a clear view of what has been earned, what is available, and what is still pending.
-21:
-22: ## The product
-23:
-24: The product sits between customer payment collection and employer payout.
-25:
-26: - A customer makes a payment.
-27: - The platform receives the payment event directly, or receives trusted payment data from a partner.
-28: - A commission engine applies employer-defined rules.
-29: - The internal ledger allocates balances between employer and employee.
-30: - A safe portion of the employee's commission becomes available immediately.
-31: - The employee can cash out instantly, and later can also spend from a wallet or card.
-32: - The employer gets the remaining balance on a defined settlement schedule.
-33: - Both sides get visibility into earnings, payouts, and performance.
-34:
-35: ## Core product layers
-36:
-37: ### Payment collection or orchestration
-38:
-39: - Accept customer payments directly, or integrate with the employer's processor.
-40: - Use payment events as the source of truth for commission creation.
-41:
-42: ### Commission rules engine
-43:
-44: - Support percentage-based, tiered, and custom rules.
-45: - Lock an auditable calculation for every sale or payment event.
-46: - Track exceptions, reversals, and dispute states.
-47:
-48: ### Ledger and balances
-49:
-50: - Maintain an internal double-entry ledger.
-51: - Track at least three states: `earned`, `available`, `settled`.
-52: - Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.
-53:
-54: ### Instant access rails
-55:
-56: - Start with instant bank transfer or `Pix` cash-out.
-57: - Later add stored balance inside the app.
-58: - Later add a prepaid or debit card linked to the balance.
-59:
-60: ### Employer analytics
-61:
-62: - Real-time commission liability.
-63: - Sales staff performance based on actual money movement.
-64: - Forecasts for payouts, reserve needs, and commission trends.
-65:
-66: ### Optional later financing layer
-67:
-68: - Employer-backed advances.
-69: - True risk-based credit only after the business has reliable repayment and reversal data.
-70:
-71: ## Recommended money flow
-72:
-73: The safest early structure is partner-led custody.
-74:
-75: - A regulated bank or licensed financial partner holds funds.
-76: - The platform owns the application layer, commission logic, ledger, and payout orchestration.
-77: - Cards, `Pix`, KYC, and regulated money movement are handled through partners.
-78:
-79: Example flow:
-80:
-81: ```text
-82: Customer pays R$1,000
-83: |
-84: v
-85: Partner-held account receives funds
-86: |
-87: v
-88: Commission engine calculates split
-89: |
-90: +-- Employee commission: R$200
-91: +-- Employer balance: R$800
-92: +-- Platform fee and reserve logic applied
-93: |
-94: v
-95: Employee sees commission balance in app
-96: |
-97: +-- Instant cash-out
-98: +-- Hold balance
-99: +-- Later: card spend
-100: ```
-101:
-102: ## Product thesis
-103:
-104: This should not start as a generic wallet, a payroll platform, or a payday loan app.
-105:
-106: The strongest wedge is:
-107:
-108: `real-time commission access tied to actual payment events`
-109:
-110: That positioning matters because it keeps the first product grounded in employer ROI, worker liquidity, and trusted payment data.
-111:
-112: ## Revenue model
-113:
-114: The business should start with software and money movement economics, not balance-sheet lending.
-115:
-116: - Platform or SaaS fee for employers.
-117: - Take rate or processing fee on payment volume.
-118: - Payout fee or bundled payout plan.
-119: - Premium analytics tier.
-120: - Later: interchange from card spend.
-121: - Later: float-sharing or treasury economics if allowed by partner structure.
-122: - Much later: advance fee for employer-backed early access products.
-123:
-124: ## What the company is not
-125:
-126: - Not a general neobank.
-127: - Not a full payroll processor.
-128: - Not a full CRM or sales engagement tool.
-129: - Not a payday lender.
-130:
-131: The company is best understood as `commission infrastructure`.
-132:
-133: ## Phased expansion
-134:
-135: ### Phase 1
-136:
-137: - Payment-linked commission calculation.
-138: - Employer and employee onboarding.
-139: - Ledger with `earned`, `available`, and `settled` states.
-140: - Instant payout access.
-141: - Employer and employee dashboards.
-142:
-143: ### Phase 2
-144:
-145: - Stored balance and wallet behavior.
-146: - Better analytics and forecasting.
-147: - Reserve and holdback controls for refunds and chargebacks.
-148: - Early employer-backed advance logic for selected customers.
-149:
-150: ### Phase 3
-151:
-152: - Card issuance.
-153: - Spend directly from balance.
-154: - More balance retention and interchange revenue.
-155: - Deeper employer integrations.
-156:
-157: ### Phase 4
-158:
-159: - Multi-entity support.
-160: - Broader partner distribution.
-161: - Carefully controlled credit products if the data and regulation support them.
-162:
-163: ## Key risks and guardrails
-164:
-165: ### Regulatory boundary
-166:
-167: - Do not begin by directly holding deposits or acting like an unlicensed financial institution.
-168: - Use a licensed partner for custody and regulated money movement.
-169:
-170: ### Reversals and chargebacks
-171:
-172: - Do not make all commissions instantly withdrawable on day one.
-173: - Use availability rules, reserves, and holdbacks.
-174:
-175: ### Commission disputes
-176:
-177: - Require explicit employer-approved rules.
-178: - Preserve a full audit trail for every calculation and adjustment.
-179:
-180: ### Labor and tax treatment
-181:
-182: - Distinguish `earned access` from `credit`.
-183: - Map payroll, withholding, and deduction obligations with counsel before product launch.
-184:
-185: ### Partner dependence
-186:
-187: - Expect early dependence on bank, card, and processor partners.
-188: - Build the ledger and business logic so the company can swap infrastructure providers later.
-189:
-190: ## Current strategic recommendation
-191:
-192: - Start in Brazil.
-193: - Lead with `Pix`-based instant access to earned commissions.
-194: - Use partner-led custody and compliance.
-195: - Treat stored balances and cards as retention tools, not the initial wedge.
-196: - Treat employer analytics as a second major value driver.
-197: - Delay true lending until the core ledger and payout engine are reliable.
-
-(End of file - total 197 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/brazil-market.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/brazil-market.md
-file
-
-1: # Tese para o mercado brasileiro
-2:
-3: ## Resumo
-4:
-5: A melhor entrada para esta ideia no Brasil e uma plataforma B2B2C que conecta recebimento, calculo de comissao, ledger interno e acesso instantaneo ao saldo via `Pix`.
-6:
-7: O produto inicial nao deve ser vendido como banco digital nem como credito ao consumidor. A tese mais forte e:
-8:
-9: `transformar cada venda validada em saldo de comissao disponivel quase em tempo real`
-10:
-11: ## Por que o Brasil primeiro
-12:
-13: - `Pix` ja criou expectativa de movimentacao instantanea e barata.
-14: - O mercado convive com atraso no pagamento de comissoes e com o uso informal de `vales`.
-15: - Existem instituicoes financeiras, cooperativas, BaaS e emissores abertos a parcerias.
-16: - Ha muitos segmentos com equipes comerciais comissionadas e operacao digital crescente.
-17: - O argumento de valor e simples: menos atraso, menos friccao operacional e mais retencao do time de vendas.
-18:
-19: ## Dor local que o produto resolve
-20:
-21: ### Para a empresa
-22:
-23: - Calculo manual de comissao.
-24: - Fechamento mensal demorado.
-25: - Falta de visibilidade sobre passivo de comissao.
-26: - Uso informal de `vales`, com pouca governanca.
-27: - Dificuldade para reconciliar recebimento, comissao, estorno e repasse final.
-28:
-29: ### Para o vendedor
-30:
-31: - Venda feita hoje, dinheiro disponivel so dias ou semanas depois.
-32: - Dependencia de `vale` para cobrir caixa pessoal.
-33: - Falta de transparencia sobre o que foi ganho, o que esta disponivel e o que ainda esta pendente.
-34:
-35: ## ICP inicial
-36:
-37: O foco deve ser empresas brasileiras com time comercial comissionado e recebimento digital identificavel.
-38:
-39: Segmentos promissores:
-40:
-41: - franquias e operacoes de varejo com vendedores comissionados
-42: - clinicas de estetica, odontologia e procedimentos eletivos
-43: - academias e servicos recorrentes com equipe de vendas
-44: - escolas, cursos e educacao privada com captacao comercial
-45: - telecom, distribuicao e revendas com metas e bonificacao variavel
-46:
-47: ## Proposta de valor no Brasil
-48:
-49: ### Para a empresa
-50:
-51: - Automatizar o calculo e o repasse de comissoes.
-52: - Reduzir dependencia de `vales` informais.
-53: - Melhorar retencao e motivacao do time.
-54: - Ter visao confiavel de performance comercial e custo de comissao.
-55: - Ganhar previsibilidade de caixa e de passivo.
-56:
-57: ### Para o colaborador
-58:
-59: - Ver a comissao quase em tempo real.
-60: - Sacar instantaneamente via `Pix` quando o saldo estiver disponivel.
-61: - Ter mais clareza sobre metas, historico e projecao de ganhos.
-62: - No futuro, usar saldo por cartao sem precisar sacar tudo.
-63:
-64: ## Produto recomendado para o Brasil
-65:
-66: ### V1
-67:
-68: - recebimento via parceiros de pagamento
-69: - motor de regras de comissao
-70: - ledger com estados `ganho`, `disponivel` e `liquidado`
-71: - saldo para colaborador e empresa
-72: - saque instantaneo via `Pix`
-73: - dashboard basico para empresa e vendedor
-74: - trilha de auditoria por transacao, comissao e ajuste
-75:
-76: ### V2
-77:
-78: - saldo retido em carteira
-79: - analytics de performance e passivo de comissao
-80: - regras de reserva para estorno e chargeback
-81: - alertas e projecoes
-82: - piloto de adiantamento com respaldo do empregador
-83:
-84: ### V3
-85:
-86: - cartao prepago ou debito
-87: - maior retencao de saldo na plataforma
-88: - integracoes com ERP, POS, CRM ou software vertical
-89:
-90: ## Parceiros locais que importam
-91:
-92: ### Infra financeira
-93:
-94: - instituicao de pagamento, banco parceiro ou BaaS para custodia e movimento regulado
-95: - exemplos de infraestrutura para avaliar: `Dock`, `QI Tech`, `Celcoin`
-96: - cooperativas e bancos menores podem ser parceiros comerciais ou institucionais, incluindo nomes como `Sicredi`, dependendo do modelo
-97:
-98: ### Processamento de pagamentos
-99:
-100: - parceiros para `Pix`, boleto e cartao
-101: - exemplos para avaliar: `Pagar.me`, `Stripe BR`, `Adyen`
-102:
-103: ### Emissao de cartao
-104:
-105: - exemplos para avaliar: `Dock`, `Pomelo`, `Swap`
-106:
-107: ### KYC e KYB
-108:
-109: - exemplos para avaliar: `idwall`, `BigDataCorp`
-110:
-111: ### Juridico e regulatorio
-112:
-113: - escritorio com experiencia em instituicao de pagamento, arranjos de pagamento, `Pix`, LGPD e temas trabalhistas
-114:
-115: ## Consideracoes regulatorias
-116:
-117: O produto encosta em varias frentes e precisa de mapeamento juridico desde cedo.
-118:
-119: - Banco Central: estrutura de `Pix`, conta transacional, instituicao de pagamento, regras de reporte e compliance.
-120: - Direito do trabalho: natureza da comissao, reflexos em folha, desconto de adiantamentos, regras contratuais com empregador.
-121: - LGPD: dados financeiros e de performance do colaborador.
-122: - CDC e transparencia: fees, prazos, disponibilidade e regras de estorno.
-123:
-124: Recomendacao pratica:
-125:
-126: - comecar debaixo da licenca e da infraestrutura de um parceiro regulado
-127: - evitar custodia direta no inicio
-128: - evitar vender o produto inicial como emprestimo
-129:
-130: ## Como tratar `vales`
-131:
-132: No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.
-133:
-134: Sequencia recomendada:
-135:
-136: - acesso ao que ja foi ganho e validado
-137: - liberacao conservadora de parte do saldo antes da liquidacao total
-138: - adiantamento com respaldo do empregador
-139: - so depois, se fizer sentido, credito com underwriting proprio
-140:
-141: Mensagem correta:
-142:
-143: - nao: `emprestimo para vendedor`
-144: - sim: `acesso controlado a comissao ja gerada`
-145:
-146: ## Go-to-market no Brasil
-147:
-148: ### Primeiro movimento
-149:
-150: - fechar 5 a 10 design partners com dor forte de comissao e operacao relativamente simples
-151: - priorizar empresas em que o evento de venda e facil de mapear ao pagamento
-152: - vender para dono, financeiro, operacoes e gestor comercial
-153:
-154: ### Canais de distribuicao
-155:
-156: - venda direta para SMB e mid-market
-157: - parceria com software vertical, POS e adquirencia
-158: - grupos de franquia
-159: - escritorios contabeis e consultorias de operacao ou folha
-160:
-161: ### Pitch inicial
-162:
-163: - reduza trabalho manual no fechamento de comissoes
-164: - de ao time acesso mais rapido ao que ja foi ganho
-165: - troque `vales` informais por um processo auditavel
-166: - tenha visao em tempo real de performance e passivo de comissao
-167:
-168: ## Modelo economico mais provavel
-169:
-170: - fee de plataforma para a empresa
-171: - fee por volume processado ou por pagamento conciliado
-172: - fee por saque, ou plano com franquia de saques
-173: - camada premium de analytics
-174: - depois: interchange de cartao
-175: - depois: compartilhamento de economia financeira, se permitido pelo arranjo com parceiro
-176:
-177: ## Principais riscos no mercado brasileiro
-178:
-179: - estorno ou chargeback depois da liberacao da comissao
-180: - disputa entre empresa e vendedor sobre regra de comissao
-181: - dependencia excessiva de um parceiro bancario ou de BaaS
-182: - classificacao regulatoria errada do produto
-183: - onboarding ruim para empresa e colaborador
-184:
-185: ## Tese final para o Brasil
-186:
-187: O melhor posicionamento nao e `mais um app de EWA` e nem `mais um banco digital`.
-188:
-189: O melhor posicionamento e:
-190:
-191: `a infraestrutura de comissao em tempo real para empresas brasileiras, com saldo disponivel via Pix e visibilidade operacional para o empregador`
-
-(End of file - total 191 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/year-one-roadmap.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/year-one-roadmap.md
-file
-
-1: # Year-One Roadmap
-2:
-3: ## Guiding principle
-4:
-5: Do not start by building a broad neobank or a consumer lending app.
-6:
-7: Start with the smallest product that proves the core wedge:
-8:
-9: `payment-linked commission calculation plus instant access to earned balances`
-10:
-11: ## Success goal for year one
-12:
-13: By the end of 12 months, the company should prove that employers will adopt a commission-led payout workflow and that employees will use it for faster access to earnings.
-14:
-15: The year-one target is not maximum feature breadth. It is proof of product-market fit for the core loop.
-16:
-17: ## Foundation and partner design
-18:
-19: ### Months 0-2
-20:
-21: #### Objectives
-22:
-23: - validate the first customer segment
-24: - choose partner model for custody, payouts, and compliance
-25: - lock the ledger and commission system design
-26:
-27: #### Workstreams
-28:
-29: - run design-partner interviews with target employers
-30: - map employer commission workflows and exception cases
-31: - choose payment and banking partner shortlist
-32: - define balance states: `earned`, `available`, `settled`
-33: - define reserve and holdback logic for reversals
-34: - specify onboarding flows for employers and employees
-35:
-36: #### Deliverables
-37:
-38: - product requirements for v1
-39: - legal and regulatory issue map
-40: - partner shortlist and integration plan
-41: - event model for payments, commissions, adjustments, and payouts
-42:
-43: #### Exit criteria
-44:
-45: - 5 to 10 serious design partners in pipeline
-46: - clear v1 scope that does not depend on lending
-47: - chosen path for `Pix` and custody infrastructure
-48:
-49: ## Core ledger and instant payout access
-50:
-51: ### Months 2-5
-52:
-53: #### Objectives
-54:
-55: - launch the first working employer flow
-56: - prove that a verified sale can become an eligible commission balance
-57: - enable instant cash-out for employees
-58:
-59: #### Product scope
-60:
-61: - employer onboarding
-62: - employee onboarding through partner KYC
-63: - payment ingestion or payment reconciliation
-64: - commission rules engine
-65: - internal ledger
-66: - employee balance with `earned`, `available`, and `settled`
-67: - employer settlement scheduling
-68: - instant payout access via `Pix` or equivalent instant transfer rail
-69: - employer dashboard with payout and commission views
-70: - employee dashboard with balance and payout history
-71:
-72: #### Operational scope
-73:
-74: - manual support for edge cases
-75: - conservative limits on instant availability
-76: - dispute and adjustment workflows
-77:
-78: #### Metrics
-79:
-80: - number of active employers
-81: - commission volume processed
-82: - payout latency
-83: - adjustment and reversal rate
-84: - employee activation rate
-85:
-86: ## Analytics and stored balance
-87:
-88: ### Months 5-8
-89:
-90: #### Objectives
-91:
-92: - make the product more valuable to employers
-93: - improve employee retention of balances
-94: - reduce the need for manual reporting
-95:
-96: #### Product scope
-97:
-98: - stored balance in the app
-99: - clearer balance segmentation and reserve visibility
-100: - employer analytics for team performance and commission liability
-101: - projections for upcoming payouts
-102: - employee insights on earnings pace and history
-103: - alerts for anomalies and budget spikes
-104: - admin tools for corrections and policy configuration
-105:
-106: #### Metrics
-107:
-108: - percent of balances retained in-platform
-109: - dashboard usage by employers
-110: - frequency of manual interventions
-111: - repeat payout behavior per employee
-112:
-113: ## Card and retention tools
-114:
-115: ### Months 8-10
-116:
-117: #### Objectives
-118:
-119: - make the balance more useful without requiring immediate cash-out
-120: - unlock interchange economics
-121:
-122: #### Product scope
-123:
-124: - prepaid or debit card issuance through a partner
-125: - spend from available balance
-126: - card controls and transaction views
-127: - balance retention incentives tied to usage, not explicit interest promises
-128: - stronger notifications and mobile experience
-129:
-130: #### Metrics
-131:
-132: - card activation rate
-133: - card spend volume
-134: - balance retention before and after card launch
-135: - support load per active user
-136:
-137: ## Scale features and controlled advance pilot
-138:
-139: ### Months 10-12
-140:
-141: #### Objectives
-142:
-143: - deepen product value for employers
-144: - test a tightly controlled version of advance functionality without becoming credit-led
-145:
-146: #### Product scope
-147:
-148: - multi-entity or franchise support
-149: - API or integration layer for ERP, CRM, or POS tools
-150: - employer cash flow forecasting
-151: - pilot of employer-backed advances with strict limits
-152: - improved risk rules for refunds, clawbacks, and employee exits
-153:
-154: #### Metrics
-155:
-156: - employer expansion within existing accounts
-157: - integration adoption
-158: - advance usage and repayment behavior
-159: - loss or exception rate on pilot advances
-160:
-161: ## What should stay out of scope in year one
-162:
-163: - standalone consumer lending
-164: - full payroll replacement
-165: - broad international expansion
-166: - feature-heavy consumer banking experience
-167: - deep CRM functionality
-168:
-169: ## Year-one product philosophy
-170:
-171: The roadmap should stay disciplined.
-172:
-173: - build the commission ledger first
-174: - prove instant access to earned money second
-175: - add retention tools third
-176: - add credit only after the company has the data and controls to support it
-177:
-178: ## Recommended milestone sequence
-179:
-180: - prove employer demand for payment-linked commission automation
-181: - prove worker demand for instant access to eligible balances
-182: - prove safe operating rules around reversals and disputes
-183: - prove that analytics improves employer retention
-184: - prove that cards increase balance retention
-185: - only then test employer-backed advance products
-
-(End of file - total 185 lines)
-
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://zrobank.com/en",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Z.ro BankZro
-
-[](/en)
-
-[Home](/en)[About Us](/en/quem-somos)
-
-Services
-
-[Local Payments](/en/servicos/pagamentos-locais)[Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)[Cryptocurrencies](/en/servicos/criptomoedas)[Financial Infratech](/en/servicos/infratech-financeira)
-
-Countries
-
-[Brazil](/en/paises/brasil)[Argentina](/en/paises/argentina)[Chile](/en/paises/chile)[Peru](/en/paises/peru)
-
-[Developers](https://coinwise-io.github.io/zrobank-doc-api/)[Contact](/en#contact)
-
-[Access your Account](https://internet-banking.zrobank.com.br/auth/login)
-
----
-
-en
-
-
-
-
-
-## The evolution
-of global
-payments starts here
-
-Welcome to the first developer-first bank, with open APIs for your company to plug in and customize your way.
-
-[Contact Us](/en#contact)
-
-## See how
-Z.ro can evolve
-your business now
-
-
-
-Local Payments
-
-Integrate with the main payment methods.
-
-
-
-Cross-Border
-
-
-
-Cryptocurrencies
-
-
-
-Banking
-
-
-
-## Who is Z.ro for?
-
-Integrate with the main payment methods.
-
-### Companies
-
-#### E-commerce
-
-#### Online Travel Agencies
-
-#### Online Gaming
-
-#### Digital Content Production
-
-#### Sports Betting
-
-#### Financial Services
-
-#### Streaming
-
-#### Other Companies
-
-#### Marketplaces
-
-#### Subscription Services
-
-## Partners
-
-### Fintechs
-
-
-
-Enjoy the best Bank as a Service infrastructure
-
-### Payment Providers
-
-
-
-Become an indirect participant of Z.ro
-
-### ERP
-
-
-
-Customize payment journeys and add revenue to your business
-
-### Digital Platforms
-
-
-
-Add the best payment methods
-
-## Become a referred business partner
-
-We certify your company to represent us in various countries. Be a trusted consultant, with our endorsement and support, wherever you are, so we can grow together.
-
-
-
-## Why Z.ro?
-
-### Technology, scale and precision
-
-- #### $10 billion
-
- transacted (in local currencies)
-
-- #### 100 million
-
- transactions
-
-- #### 50 thousand
-
- payments per minute at daily peaks
-
-- #### 1 million
-
- app downloads
-
-- #### 99.98%
-
- conversion rate
-
-
-### Credibility and trust
-
-- #### 150
-
- employees in 4 countries
-
-- #### A-level company
-
- in the Central Bank of Brazil ranking
-
-- #### Ernst & Young and KPMG
-
- Audited by
-
-- #### Multinvest Capital
-
- Invested by
-
-- #### Endeavor, Visa, BID and Itaú
-
- Accelerated by
-
-
-## In the media
-
-
-
-Z.ro Bank launches international payments with crypto assets following Central Bank regulation
-
-[Read Article](https://www1.folha.uol.com.br/colunas/painelsa/2025/12/zro-bank-lanca-pagamentos-internacionais-com-criptoativos-apos-regulacao-do-bc.shtml)
-
-
-
-Fintech launches robot that buys tickets and places bets
-
-[Read Article](https://www1.folha.uol.com.br/colunas/painelsa/2025/03/fintech-lanca-robo-que-compra-ingressos-e-faz-apostas.shtml)
-
-
-
-Zro Bank obtains a payment institution license
-
-[Read Article](https://valor.globo.com/financas/noticia/2024/07/24/zro-bank-obtm-licena-de-instituio-de-pagamento.ghtml)
-
-
-
-Brazilian bank combining the real and cryptocurrencies receives a R$25 million investment
-
-[Read Article](https://exame.com/future-of-money/banco-brasileiro-que-une-real-e-criptomoedas-recebe-aporte-de-r25-milhoes/)
-
-
-
-This Recife-based business has already processed R$45 billion and now aims to take Pix to the world
-
-[Read Article](https://exame.com/negocios/este-negocio-de-recife-ja-processou-r-22-bilhoes-e-agora-quer-levar-o-pix-para-o-mundo/)
-
-
-
-Zro Bank, of cryptocurrencies, will receive a contribution of up to R$ 61 million
-
-[Read Article](https://valor.globo.com/financas/noticia/2021/10/19/zro-bank-de-criptomoeda-recebe-aporte-de-r-61-mi.ghtml)
-
-
-
-Multicurrency chatbank, Zro Bank wants to be the Brazilian WeChat
-
-[Read Article](https://forbes.com.br/forbes-money/2021/01/chatbank-multimoeda-zro-bank-quer-ser-o-wechat-brasileiro/)
-
-
-
-Brazilian fintech Z.ro Bank expands into Latin America
-
-[Read Article](https://www.estadao.com.br/economia/coluna-do-broad/fintech-brasileira-zro-bank-expande-para-america-latina)
-
-
-
-## Contact Us
-
-Subject
-
-By continuing, you allow Z.ro Bank to contact you through the provided channels.
-
-Send
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-
-
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-
-#### Services
-
-- [Local Payments](/en/servicos/pagamentos-locais)
-- [Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)
-- [Cryptocurrencies](/en/servicos/criptomoedas)
-- [Financial Infratech](/en/servicos/infratech-financeira)
-- [Digital Account](/en/paises/brasil#digital-account)
-
-#### Countries
-
-- [Brazil](/en/paises/brasil)
-- [Argentina](/en/paises/argentina)
-- [Chile](/en/paises/chile)
-- [Peru](/en/paises/peru)
-
-#### Transparency
-
-- [Ethics and Compliance](/en/transparencia#ethics-and-compliance)
-- [Privacy Policy](/en/politicas-de-privacidade)
-- [Terms of Use](/en/termos-de-uso)
-- [Reporting Channel Policy](/en/politicas-canal-denuncias)
-
-[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)[](https://apps.apple.com/br/app/zro-bank-multimoedas/id1528780452)
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 18.6s)
-
-_Thinking:_
-
-**Researching Z.ro documentation**
-
-I need to dive into the Z.ro documentation to tailor it for our startup launch. Using webfetch on their docs site seems essential, potentially involving both the browser and webfetch tools. Since it could be a GitHub Pages site, I should check if the open API spec is available. I might ask clarifying questions, but I can likely move forward. I’ll categorize what Z.ro covers, what we still need to build, and what we need to confirm with them. Using todowrite might help, but it might not be necessary yet.
-
-Pulling the developer docs and the Brazil/product-specific pages next so I can separate what Z.ro can handle for us from what we still need to build ourselves.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Z.ro Bank | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-
-
-# Z.ro Bank
-
-Documentation
-
-[Get Started](/overview/introduction)
-
-
-
-
-
-### Pix as a Service
-
-Send and receive instant payments through our Pix API, quickly and safely.
-
-[See more](/paas/api-overview/introduction)
-
-
-
-### Zro Gateway
-
-Manage your wallets, track your transactions, and enjoy availability across multiple banks with the lowest fees.
-
-[See more](/gateway/api-overview/introduction)
-
-
-
-### Crypto as a Service
-
-Increase liquidity in your operations and offer your customers the most popular cryptocurrencies on your website or app, using our Crypto API.
-
-[See more](/caas/api-overview/introduction)
-
-
-
-### Payments Gateway
-
-Accept card payments with agility and security through our Payments Gateway API, enabling seamless integration for in-person and online transactions.
-
-[See more](https://docs-international.zrobank.io)
-
-
-
-Customer support: alo@zrobank.com.br | LGPD: dpo.zro@zrobank.com.br | CNPJ: 26.264.220/0001-16
-
-[](https://www.linkedin.com/company/zrobank)[](https://www.instagram.com/zrobank)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://zrobank.com/en/paises/brasil",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Z.ro BankBrazil - Zro
-
-[](/en)
-
-[Home](/en)[About Us](/en/quem-somos)
-
-Services
-
-[Local Payments](/en/servicos/pagamentos-locais)[Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)[Cryptocurrencies](/en/servicos/criptomoedas)[Financial Infratech](/en/servicos/infratech-financeira)
-
-Countries
-
-[Brazil](/en/paises/brasil)[Argentina](/en/paises/argentina)[Chile](/en/paises/chile)[Peru](/en/paises/peru)
-
-[Developers](https://coinwise-io.github.io/zrobank-doc-api/)[Contact](/en/paises/brasil#contact)
-
-[Access your Account](https://internet-banking.zrobank.com.br/auth/login)
-
----
-
-en
-
-
-
-
-
-# See what Z.ro offers to help your business take off in Brazil.
-
-
-
-
-
-### Pix
-
-Send and receive Pix at hyperscale, automating your payment flows.
-
-
-
-### Exchange (eFX)
-
-Process local payments and automatically close currency exchange for international transfers.
-
-
-
-### Other Payments
-
-Accept credit cards, debit cards, and various digital wallets, with just one connection.
-
-
-
-### Cryptocurrencies
-
-Pay, receive, and make instant conversions of over 100 cryptocurrencies.
-
-### Specialists
-in what we do
-
-- #### 50 billion
-
- Reais transacted
-
-- #### 100 million
-
- transactions
-
-- #### 50 thousand
-
- transactions per minute at daily peaks
-
-- #### 1 million
-
- app downloads
-
-- #### 99.98%
-
- conversion rate
-
-
-### Credibility
-and trust
-
-- #### A-level company
-
- in the Central Bank of Brazil ranking
-
-- #### Ernst & Young and KPMG
-
- Audited by
-
-- #### Multinvest Capital
-
- Invested by
-
-- #### Endeavor, Visa, BID and Itaú
-
- Accelerated by
-
-- #### 150
-
- employees in 4 countries
-
-
-## Partners
-
-### Fintechs
-
-
-
-Enjoy the best Bank as a Service infrastructure
-
-### Payment Providers
-
-
-
-Become an indirect participant of Z.ro
-
-### ERP
-
-
-
-Customize payment journeys and add revenue to your business
-
-### Digital Platforms
-
-
-
-Add the best payment methods
-
-## For your company
-
-
-
-#### Integrate our API into your system and automate your financials
-
-
-
-#### Send and receive payments via Pix at hyperscale
-
-
-
-#### Reduce fraud with our security layers
-
-
-
-#### Schedule automatic refunds and returns
-
-
-
-#### Program slips upon receiving via Pix for as many accounts as you want
-
-
-
-#### Start issuing static and dynamic QR Codes
-
-
-
-#### Track all your operations in real-time
-
-
-
-#### Receive Webhook notifications for all operations
-
-
-
-#### Reconcile your payments quickly and simply
-
-
-
-#### Make scheduled Pix, reducing costs with automatic debit
-
-## For you
-
-### Multi-currency digital account
-
-At Z.ro, you have a free digital account, with a VISA debit card and cryptocurrency conversion, all in one place. It's like an Exchange, but inside your bank.
-
-
-
-
-
-
-
-## Contact Us
-
-Subject
-
-By continuing, you allow Z.ro Bank to contact you through the provided channels.
-
-Send
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-
-
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-
-#### Services
-
-- [Local Payments](/en/servicos/pagamentos-locais)
-- [Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)
-- [Cryptocurrencies](/en/servicos/criptomoedas)
-- [Financial Infratech](/en/infratech-financeira)
-- [Digital Account](/en/paises/brasil#digital-account)
-
-[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)[](https://apps.apple.com/br/app/zro-bank-multimoedas/id1528780452)
-
-#### Transparency
-
-- [Privacy Policy](/en/politicas-de-privacidade)
-- [Security policy](/en/politicas-de-seguranca)
-- [Terms of Use](/en/termos-de-uso)
-- [Reporting Channel Policy](/en/politicas-canal-denuncias)
-
-#### Regulatory
-
-- [Ethics and Compliance](/en/transparencia#ethics-and-compliance)
-- [Whistleblowing channel](/en/transparencia#reporting-channel)
-- [Scam manual](https://drive.google.com/file/d/1kRNIA23YYz_8r3y9tZ9okeEZX3D8UGEc/view)
-- [Risk manual](/en/manual-de-gerenciamento-do-risco-de-liquidez)
-
-#### Support
-
-#### SAC
-
-- [\[email protected\]](/cdn-cgi/l/email-protection#4f222a2e253a2b2e0f353d202d2e2124612c2022612d3d)
-- [(11) 5043-6444](tel:1150436444)
-
-[Customer support](/en/ouvidoria)
-
-#### LGPD (Marcelo Bueno Carneiro)
-
-- [\[email protected\]](/cdn-cgi/l/email-protection#b3d7c3dc9dc9c1dcf3c9c1dcd1d2ddd89dd0dcde9dd1c1)
-
-[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://zrobank.com/en/servicos/infratech-financeira",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Z.ro BankFinancial Infratech - Zro
-
-[](/en)
-
-[Home](/en)[About Us](/en/quem-somos)
-
-Services
-
-[Local Payments](/en/servicos/pagamentos-locais)[Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)[Cryptocurrencies](/en/servicos/criptomoedas)[Financial Infratech](/en/servicos/infratech-financeira)
-
-Countries
-
-[Brazil](/en/paises/brasil)[Argentina](/en/paises/argentina)[Chile](/en/paises/chile)[Peru](/en/paises/peru)
-
-[Developers](https://coinwise-io.github.io/zrobank-doc-api/)[Contact](/en/servicos/infratech-financeira#contact)
-
-[Access your Account](https://internet-banking.zrobank.com.br/auth/login)
-
----
-
-en
-
-
-
-
-
-# Enjoy the entire infrastructure of Latin America's first developer-first bank.
-
-All our open APIs for your company to plug in and customize. Your way.
-
-
-
-### Fintechs
-
-Enjoy our Bank as a Service infrastructure
-
-
-
-### Payment Providers
-
-Become an indirect participant
-
-
-
-### ERP
-
-Create payment journeys and add revenue to your business
-
-
-
-### Digital Platforms
-
-Add the best payment methods
-
-
-
-### Backoffice
-
-Manage your sub-account ecosystem with all the features and reports needed for your business to grow.
-
-
-
-### Payment Gateway
-
-Offer various payment methods connected in a single gateway.
-
-
-
-### Internet Banking
-
-Provide a complete Banking platform for your stakeholders.
-
-
-
-### White-label Application
-
-Personalize and adapt our Bank's application for your customers with your brand.
-
-
-
-## Contact Us
-
-Subject
-
-By continuing, you allow Z.ro Bank to contact you through the provided channels.
-
-Send
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-
-
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-
-#### Services
-
-- [Local Payments](/en/servicos/pagamentos-locais)
-- [Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)
-- [Cryptocurrencies](/en/servicos/criptomoedas)
-- [Financial Infratech](/en/servicos/infratech-financeira)
-- [Digital Account](/en/paises/brasil#digital-account)
-
-#### Countries
-
-- [Brazil](/en/paises/brasil)
-- [Argentina](/en/paises/argentina)
-- [Chile](/en/paises/chile)
-- [Peru](/en/paises/peru)
-
-#### Transparency
-
-- [Ethics and Compliance](/en/transparencia#ethics-and-compliance)
-- [Privacy Policy](/en/politicas-de-privacidade)
-- [Terms of Use](/en/termos-de-uso)
-- [Reporting Channel Policy](/en/politicas-canal-denuncias)
-
-[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)[](https://apps.apple.com/br/app/zro-bank-multimoedas/id1528780452)
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://zrobank.com/en/servicos/pagamentos-locais",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Z.ro BankLocal Payments - Zro
-
-[](/en)
-
-[Home](/en)[About Us](/en/quem-somos)
-
-Services
-
-[Local Payments](/en/servicos/pagamentos-locais)[Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)[Cryptocurrencies](/en/servicos/criptomoedas)[Financial Infratech](/en/servicos/infratech-financeira)
-
-Countries
-
-[Brazil](/en/paises/brasil)[Argentina](/en/paises/argentina)[Chile](/en/paises/chile)[Peru](/en/paises/peru)
-
-[Developers](https://coinwise-io.github.io/zrobank-doc-api/)[Contact](/en/servicos/pagamentos-locais#contact)
-
-[Access your Account](https://internet-banking.zrobank.com.br/auth/login)
-
----
-
-en
-
-
-
-
-
-# One integration, multiple possibilities
-
-Scale your business with the main payment methods. All with centralized management on a platform awarded as the best technological solution in the Latin American financial market.
-
-## Much more than credit and debit cards
-
-Receive payments through digital wallets as well and convert many more sales, allowing your customer to pay how they want.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## Discover the solutions only Z.ro offers for your company
-
-
-
-### Conversion
-
-Convert more of your sales, with our APIs that guarantee an average conversion rate of 99.8%
-
-
-
-### Scale
-
-We grow exponentially together. Our platform has record peaks of 50,000 transactions per minute to sustain your sales peaks.
-
-
-
-### Monitoring
-
-Manage your business through our specialized dashboards for your segment.
-
-
-
-### Control
-
-Automatic reconciliation and personalized reports for your company.
-
-
-
-### Conversion
-
-Convert more of your sales, with our APIs that guarantee an average conversion rate of 99.8%
-
-
-
-### Scale
-
-We grow exponentially together. Our platform has record peaks of 50,000 transactions per minute to sustain your sales peaks.
-
-
-
-### Monitoring
-
-Manage your business through our specialized dashboards for your segment.
-
-
-
-### Control
-
-Automatic reconciliation and personalized reports for your company.
-
-
-
-## Contact Us
-
-Subject
-
-By continuing, you allow Z.ro Bank to contact you through the provided channels.
-
-Send
-
-[](https://www.linkedin.com/company/zrobank/)[](https://www.instagram.com/zrobank/)
-
-
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-
-#### Services
-
-- [Local Payments](/en/servicos/pagamentos-locais)
-- [Cross-border Payments (eFX)](/en/servicos/pagamentos-cross-border)
-- [Cryptocurrencies](/en/servicos/criptomoedas)
-- [Financial Infratech](/en/servicos/infratech-financeira)
-- [Digital Account](/en/paises/brasil#digital-account)
-
-#### Countries
-
-- [Brazil](/en/paises/brasil)
-- [Argentina](/en/paises/argentina)
-- [Chile](/en/paises/chile)
-- [Peru](/en/paises/peru)
-
-#### Transparency
-
-- [Ethics and Compliance](/en/transparencia#ethics-and-compliance)
-- [Privacy Policy](/en/politicas-de-privacidade)
-- [Terms of Use](/en/termos-de-uso)
-- [Reporting Channel Policy](/en/politicas-canal-denuncias)
-
-[](https://play.google.com/store/apps/details?id=br.com.zrobank.app&hl=pt_BR)[](https://apps.apple.com/br/app/zro-bank-multimoedas/id1528780452)
-
-[](https://www.instagram.com/zrobank/)[](https://www.linkedin.com/company/zrobank/)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 18.7s)
-
-_Thinking:_
-
-**Understanding service requirements**
-
-I need to get a clear picture of the services available. It seems like for the MVP with Z.ro, we require certain APIs, modules, and contractual setups. I'll have to check the API documentation for details on authentication, entities, and endpoints.
-
-It's also essential to find out if they support features like webhooks, KYC, and payment gateways. I might need to do a parallel webfetch on specific documentation pages to gather all necessary information. Let’s explore those docs!
-
-_Thinking:_
-
-**Exploring API documentation needs**
-
-I need to identify specific API documentation pages for auth, webhooks, and services like Pix for cash transactions and wallets. Since the user is asking for exact requirements, I should create a thorough mapping.
-
-I'll look at the site structure of the documentation, potentially using webfetch or GitHub insights since they’re on GitHub Pages. I might fetch the sitemap or simply inspect the navigation through the browser to know what paths I need to follow. This way, I can gather all necessary information.
-
-Looking into the actual API docs now to identify the concrete modules, auth model, and operational pieces we would need to contract or build around.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/overview/introduction",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Introduction | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [Overview](/overview/introduction)
-
- - [Introduction](/overview/introduction)
- - [Security](/overview/security)
- - [Environments](/overview/environments)
- - [Support](/overview/support)
-
-- [](/)
-- Overview
-- Introduction
-
-# Introduction
-
-Welcome to Z.ro Bank!
-
-Here you'll find all the information you must have to integrate with Z.ro Bank and our API endpoints. We've tried to build this documentation as user-friendly as possible, creating a simple and gentle experience for you.
-
-# Overview
-
-Z.ro Bank is a Brazilian digital bank and cryptocurrency exchange based on blockchain technology. We build financial services for customers and their businesses using proprietary technology.
-
-**Z.RO FOR BUSINESS** \- Made for your company
-
-For institutional clients, we build all crypto and payments infrastructure using the best practices and technology available. Count on us to always deliver the software your company needs to reach its full potential.
-
-# What is Pix?
-
-Pix is a new instant payment system that was launched in Brazil, November 2020. This system allows individuals and businesses to make instant money transfers through a mobile app or online banking platform. The main advantage of Pix is that it is available 24/7, including holidays, and the transactions are processed instantly.
-
-One of the benefits of Pix is that it is a cheaper and faster alternative to traditional payment methods, such as bank transfers, and credit cards. There are no fees for individuals and small businesses to use Pix. Large businesses may incur fees depending on the volume of transactions.
-
-On our Pix as a Service API, you can send and receive money by a Pix Key, dynamic QR code or bank account.
-
-The Pix payment system, through Pix keys, works by allowing users to link a unique identification process, such as a phone number, email address, document number or random key, to their bank account. When making a payment, the user simply provides a Pix key instead of bank account information. Pix dynamic QR code works by allowing the payer to scan or copy the QR code created by the merchant or service provider. The QR code contains information such as the payment amount and the recipient’s account details. The use of dynamic QR codes allows for greater security and flexibility in payments, as the code is generated for each individual transaction, reducing the risk of fraudulent activity. In order to receive a Pix Payment, if you didn’t register a pix key, you can use your bank account information on Pix. You can use the data that is usually provided by a traditional bank, the money will then be credited to the recipient’s account instantly as a Pix Payment.
-
-You can find more information on Pix on Central Bank FAQ section on its website [https://www.bcb.gov.br/en/financialstability/pixfaqen](https://www.bcb.gov.br/en/financialstability/pixfaqen)
-
-# Questions?
-
-It’s always a pleasure to help you! If you require assistance with the integration or have any questions, please feel free to use our documentation and do not hesitate to [contact us](/overview/support).
-
-[
-
-Next
-
-Security
-
-](/overview/security)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/paas/api-overview/introduction",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Introduction | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/paas/api-overview/introduction)
-
- - [Introduction](/paas/api-overview/introduction)
- - [Authentication](/paas/api-overview/authentication)
- - [Protocol](/paas/api-overview/protocol)
- - [Idempotence](/paas/api-overview/idempotence)
- - [Rate Limiting](/paas/api-overview/rate-limiting)
- - [Request ID (Nonce)](/paas/api-overview/request-id)
- - [Serialization](/paas/api-overview/serialization)
- - [Replay Protection](/paas/api-overview/replay)
- - [Pagination](/paas/api-overview/pagination)
- - [API Responses](/paas/api-overview/api-responses)
- - [Changelog](/paas/api-overview/changelog)
- - [Webhooks](/paas/api-overview/webhooks)
-- [Endpoints](/paas/endpoints/zro-global-paas-api)
-
-
-- [](/)
-- API Overview
-- Introduction
-
-On this page
-
-# Introduction
-
-Welcome to the Z.ro Bank Pix-as-a-Service (PaaS) API documentation. Our API provides a comprehensive set of endpoints to enable developers to build powerful applications that interact with our technology.
-
-This documentation provides all the necessary information to help you integrate with our API seamlessly. So let's get started and explore the exciting world of Pix with our Z.ro Bank PaaS API.
-
-## API ID and API Key Setup[](#api-id-and-api-key-setup "Direct link to API ID and API Key Setup")
-
-Once your `API ID` and `API Key` are created, you are ready to start the integration.
-
-- If you have not registered your company yet, please access: [Register to Z.ro Bank PaaS API](https://docs.google.com/forms/d/e/1FAIpQLSdMHWF1sZm7jjSsKiYGZIcd7sN2vCwx_OH5Eh3W1X8n7wS6ug/viewform)
-
-- If you have already registered your company, but your credentials were not provided yet, please contact our [support team](/overview/support).
-
-
-> Note: Never share your `API ID` and `API Key` to anyone. If you have accidentally shared, please contact our [support team](/overview/support) immediately.
-
-## API Base URLs[](#api-base-urls "Direct link to API Base URLs")
-
-- **Test environment:** [](https://paas-hml.zrobank.xyz/api)[https://paas-hml.zrobank.xyz/api](https://paas-hml.zrobank.xyz/api)
-
-[
-
-Next
-
-Authentication
-
-](/paas/api-overview/authentication)
-
-- [API ID and API Key Setup](#api-id-and-api-key-setup)
-- [API Base URLs](#api-base-urls)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/api-overview/introduction",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Introduction | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
- - [Introduction](/baas/api-overview/introduction)
- - [Authentication](/baas/api-overview/authentication)
- - [Protocol](/baas/api-overview/protocol)
- - [Idempotence](/baas/api-overview/idempotence)
- - [Rate Limiting](/baas/api-overview/rate-limiting)
- - [Request ID (Nonce)](/baas/api-overview/request-id)
- - [Serialization](/baas/api-overview/serialization)
- - [Replay Protection](/baas/api-overview/replay)
- - [Pagination](/baas/api-overview/pagination)
- - [API Responses](/baas/api-overview/api-responses)
- - [Changelog](/baas/api-overview/changelog)
- - [Webhooks](/baas/api-overview/webhooks)
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- API Overview
-- Introduction
-
-On this page
-
-# Introduction
-
-Welcome to the Z.ro Bank Banking-as-a-Service (BaaS) API documentation. Our API provides a comprehensive set of endpoints to enable developers to build powerful applications that interact with our technology.
-
-This documentation provides all the necessary information to help you integrate with our API seamlessly. So let's get started and explore the exciting world of Banking with our Z.ro Bank BaaS API.
-
-## API ID and API Key Setup[](#api-id-and-api-key-setup "Direct link to API ID and API Key Setup")
-
-Once your `API ID` and `API Key` are created, you are ready to start the integration.
-
-- If you have not registered your company yet, please access: [Register to Z.ro Bank BaaS API](https://docs.google.com/forms/d/e/1FAIpQLSdMHWF1sZm7jjSsKiYGZIcd7sN2vCwx_OH5Eh3W1X8n7wS6ug/viewform)
-
-- If you have already registered your company, but your credentials were not provided yet, please contact our [support team](/overview/support).
-
-
-> Note: Never share your `API ID` and `API Key` to anyone. If you have accidentally shared, please contact our [support team](/overview/support) immediately.
-
-## API Base URLs[](#api-base-urls "Direct link to API Base URLs")
-
-- **Test environment:** [](https://api-baas-hml.zrobank.xyz/api)[https://api-baas-hml.zrobank.xyz/api](https://api-baas-hml.zrobank.xyz/api)
-
-[
-
-Next
-
-Authentication
-
-](/baas/api-overview/authentication)
-
-- [API ID and API Key Setup](#api-id-and-api-key-setup)
-- [API Base URLs](#api-base-urls)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/gateway/api-overview/introduction",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Introduction | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/gateway/api-overview/introduction)
-
- - [Introduction](/gateway/api-overview/introduction)
- - [Authentication](/gateway/api-overview/authentication)
- - [Protocol](/gateway/api-overview/protocol)
- - [Serialization](/gateway/api-overview/serialization)
- - [Errors](/gateway/api-overview/errors)
- - [How to use](/gateway/api-overview/how-to-use)
- - [API Responses](/gateway/api-overview/api-responses)
- - [Duplication Prevention](/gateway/api-overview/duplication-prevention)
- - [Changelog](/gateway/api-overview/changelog)
- - [Webhooks](/gateway/api-overview/webhooks)
-- [Endpoints](/gateway/endpoints/zrobank)
-
-
-- [](/)
-- API Overview
-- Introduction
-
-On this page
-
-# Introduction
-
-Welcome to the Z.ro Gateway API documentation. Our API provides a comprehensive set of endpoints to enable developers to build powerful applications that interact with our technology.
-
-This documentation provides all the necessary information to help you integrate with our API seamlessly. So let’s get started and explore the world of payments with our Z.ro Gateway API.
-
-## Authentication[](#authentication "Direct link to Authentication")
-
-There are two types of authentication methods available for the Z.ro Gateway API:
-
-- Using PaaS Token
-- Using `x-api-key` (DEPRECATED)
-
-You can see the details of each authentication method at the [Authentication section](/gateway/api-overview/authentication).
-
-## API Base URLs[](#api-base-urls "Direct link to API Base URLs")
-
-- **Test environment:** [](https://payments-api-hml.zrobank.xyz/api/documentation)[https://payments-api-hml.zrobank.xyz/api/documentation](https://payments-api-hml.zrobank.xyz/api/documentation)
-
-[
-
-Next
-
-Authentication
-
-](/gateway/api-overview/authentication)
-
-- [Authentication](#authentication)
-- [API Base URLs](#api-base-urls)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 16.4s)
-
-_Thinking:_
-
-**Analyzing Z.ro Bank Services**
-
-The user is interested in Z.ro Bank for its service offerings, and I need to review their documentation to see what fits our needs. I plan to dive into their endpoint docs to fully understand their capabilities, inspecting their API lists related to PaaS and BaaS. It’s essential to identify the modules necessary for our launch, including aspects like KYB/KYC support and various payment features. I might also consider using web scraping for a deeper examination of their endpoints.
-
-_Thinking:_
-
-**Examining Z.ro Bank Requirements**
-
-I need to pinpoint exact endpoints and requirements like API credentials, onboarding processes, and legal documents. Since we’re in plan mode, using webfetch could help, but the accessible site docs might be sufficient. I plan to inspect endpoint listings for BaaS and PaaS capabilities and review guides. It’s crucial to clarify what we need from Z.ro Bank and what parts we’ll build ourselves. I might highlight any unanswered questions stemming from gaps in the documentation. Let's get into those relevant docs!
-
-_Thinking:_
-
-**Defining PaaS and BaaS Needs**
-
-I need to consider PaaS features for things like Pix transactions, QR codes, webhooks, and refunds. A payment gateway might come in handy later if we want card acceptance. I’m also weighing the need for a white-label app and a Visa debit card for future use. It’s essential to find out if BaaS includes debit card issuance or digital accounts. I'll inspect endpoint listings and onboarding guides for insights on bank account management and other functionalities. Let’s gather that information!
-
-I’ve got the high-level product fit. Now I’m checking endpoint coverage and onboarding guides so the recommendation is concrete rather than just “they look compatible.”
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/zro-global-baas-api",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Zro Global Baas API | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Introduction
-
-Version: 1.82.0
-
-Export
-
-- [OpenAPI Spec](/specs/baas-spec.json)
-
-# Zro Global Baas API
-
-Zro Global Baas API
-
-## Authentication[](#authentication "Direct link to Authentication")
-
-- HTTP: Bearer Auth
-
-Security Scheme Type:
-
-http
-
-HTTP Authorization Scheme:
-
-bearer
-
-Bearer format:
-
-JWT
-
-### Contact
-
-Z.ro Bank: [tecnologia@zrobank.com.br](mailto:tecnologia@zrobank.com.br)URL: [https://www.zrobank.com.br](https://www.zrobank.com.br)
-
-### License
-
-[All rights reserved](https://www.zrobank.com.br)
-
-[
-
-Previous
-
-Natural Person Onboarding
-
-](/baas/guides/natural-person-onboarding)[
-
-Next
-
-Create Access Token for Login
-
-](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/paas/endpoints/zro-global-paas-api",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Zro Global Paas API | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/paas/api-overview/introduction)
-
-- [Endpoints](/paas/endpoints/zro-global-paas-api)
-
- - [Introduction](/paas/endpoints/zro-global-paas-api)
- - [Authentication](/paas/endpoints/login-auth-rest-controller-execute)
-
- - [Pix | Keys](/paas/endpoints/get-all-pix-key-rest-controller-execute)
-
- - [Pix | Keys | Dynamic QR Code](/paas/endpoints/create-qr-code-dynamic-instant-billing-rest-controller-execute)
-
- - [Pix | Keys | Static QR Code](/paas/endpoints/get-all-qr-code-static-rest-controller-execute)
-
- - [Split Payments](/paas/endpoints/create-split-pix-qr-code-static-rest-controller-execute)
-
- - [Pix | Payments](/paas/endpoints/v-2-create-decoded-qr-code-rest-controller-execute-v-2)
-
- - [Pix | Devolutions](/paas/endpoints/create-pix-devolution-rest-controller-execute)
-
- - [Pix | Deposits](/paas/endpoints/v-5-get-all-pix-deposit-rest-controller-execute-v-5)
-
- - [Otc | Conversions](/paas/endpoints/v-2-create-conversion-rest-controller-execute-v-2)
-
- - [Quotations | Conversions](/paas/endpoints/v-2-get-quotation-rest-controller-execute-v-2)
-
- - [Operations | Wallets](/paas/endpoints/get-all-wallet-rest-controller-execute)
-
- - [Operations | P2P Transfers](/paas/endpoints/create-p-2-p-transfer-rest-controller-execute)
-
- - [Operations | Wallet Accounts](/paas/endpoints/get-all-wallet-account-rest-controller-execute)
-
- - [Operations | Currency](/paas/endpoints/get-all-currency-rest-controller-execute)
-
- - [Operations | Operation](/paas/endpoints/get-all-operations-rest-controller-execute)
-
- - [Operations | Wallet limits](/paas/endpoints/update-wallet-limit-rest-controller-execute)
-
- - [Banking](/paas/endpoints/v-2-get-all-banking-ted-received-rest-controller-execute-v-2)
-
- - [Banking | Bank Billet | Pix Deposits](/paas/endpoints/create-banking-billet-pix-deposit-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Template](/paas/endpoints/create-banking-billet-pix-deposit-template-rest-controller-execute)
-
- - [Banking | Bank Billet | Payments](/paas/endpoints/get-banking-billet-payment-by-id-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/paas/endpoints/create-banking-billet-pix-deposit-batch-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/paas/endpoints/create-banking-billet-pix-deposit-batch-item-rest-controller-execute)
-
- - [Utils | User Withdraw Settings](/paas/endpoints/get-all-user-withdraw-setting-rest-controller-execute)
-
- - [Health](/paas/endpoints/health-controller-execute)
-
- - [Reports](/paas/endpoints/v-5-generate-pix-statement-export-rest-controller-execute-v-5)
-
- - [Storage](/paas/endpoints/get-all-files-rest-controller-execute)
-
- - [Users | User Bank Account](/paas/endpoints/get-user-bank-account-by-wallet-rest-controller-execute)
-
- - [Pix | Recurrence](/paas/endpoints/create-pix-recurrence-rest-controller-execute)
-
- - [Pix | Scheduled Payments](/paas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute)
-
- - [Pix | Automatic Receiver Limits](/paas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute)
-
- - [Card](/paas/endpoints/create-virtual-card-rest-controller-execute)
-
- - [Card | Onboarding](/paas/endpoints/get-terms-of-use-rest-controller-execute)
-
- - [Open Finance | Participants](/paas/endpoints/get-all-open-finance-participants-rest-controller-execute)
-
- - [Open Finance | Payment Consents](/paas/endpoints/create-open-finance-payment-consent-by-pix-key-rest-controller-execute)
-
- - [Open Finance | Payments](/paas/endpoints/create-open-finance-payment-rest-controller-execute)
-
- - [Schemas](/paas/endpoints/schemas/authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Introduction
-
-Version: 1.82.0
-
-Export
-
-- [OpenAPI Spec](/specs/paas-spec.json)
-
-# Zro Global Paas API
-
-Zro Global Paas API
-
-## Authentication[](#authentication "Direct link to Authentication")
-
-- HTTP: Bearer Auth
-
-Security Scheme Type:
-
-http
-
-HTTP Authorization Scheme:
-
-bearer
-
-Bearer format:
-
-JWT
-
-### Contact
-
-Z.ro Bank: [tecnologia@zrobank.com.br](mailto:tecnologia@zrobank.com.br)URL: [https://www.zrobank.com.br](https://www.zrobank.com.br)
-
-### License
-
-[All rights reserved](https://www.zrobank.com.br)
-
-[
-
-Previous
-
-Webhooks
-
-](/paas/api-overview/webhooks)[
-
-Next
-
-Create Access Token for Login
-
-](/paas/endpoints/login-auth-rest-controller-execute)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/guides/legal-person-onboarding",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Legal Person Onboarding | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
- - [Legal Person Onboarding](/baas/guides/legal-person-onboarding)
- - [Natural Person Onboarding](/baas/guides/natural-person-onboarding)
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- Guides
-- Legal Person Onboarding
-
-On this page
-
-# Legal Person Onboarding
-
-Complete flow for onboarding a Legal Person through the BaaS API.
-
-## Flow Overview[](#flow-overview "Direct link to Flow Overview")
-
-Execute steps 1-7 in order.
-
----
-
-## Step 1: Create User Account[](#step-1-create-user-account "Direct link to Step 1: Create User Account")
-
-`POST /users/accounts`
-
-Create user account as Legal Person with CNPJ.
-
-**Returns:** `user_id`
-
----
-
-## Step 2: Create Onboarding[](#step-2-create-onboarding "Direct link to Step 2: Create Onboarding")
-
-`POST /users/onboarding/legal-person`
-
-Create onboarding record with legal person address and revenue.
-
-**Returns:** `onboarding_id` → Save for Steps 6 and 7
-
-**Note:** Cannot create if user has active onboarding (PENDING, IN\_PROCESS, FINISHED). Can create new if previous was REJECTED or FAILED.
-
----
-
-## Step 3: Create Shareholders[](#step-3-create-shareholders "Direct link to Step 3: Create Shareholders")
-
-`POST /users/shareholders`
-
-Register shareholders. Can be Natural Person (CPF) or Legal Person (CNPJ).
-
-**Returns:** `shareholder_id` → Save for Step 4 (Natural Person shareholders only)
-
-**Requirements:**
-
-- At least one shareholder
-- If shareholder is Natural Person (CPF), the `document` must match the legal representative's document created in Step 4
-- Legal Person (CNPJ) shareholders do not require a legal representative
-- Total `participation_percentage` ≤ 100%
-
----
-
-## Step 4: Create Legal Representatives[](#step-4-create-legal-representatives "Direct link to Step 4: Create Legal Representatives")
-
-`POST /users/legal-representatives`
-
-Register legal representatives. Must be Natural Person with CPF.
-
-**Requires:** `shareholder_id` from Step 3
-
-**Returns:** `legal_representative_id` → Save for Step 5
-
-**Requirements:**
-
-- Must be Natural Person (CPF)
-- Must link to a Natural Person shareholder via `shareholder_id`
-- At least one legal representative required
-
----
-
-## Step 5: Upload Representative Documents[](#step-5-upload-representative-documents "Direct link to Step 5: Upload Representative Documents")
-
-`POST /users/legal-representatives/{id}/documents`
-
-Upload documents for each legal representative (multipart/form-data).
-
-**Required:**
-
-- `selfie` (file)
-- `identity_document` (file)
-- `identity_document_type` (enum: `id`, `cnh`, `passaporte`)
-- `qualification_declaration` (file)
-
-**Optional:**
-
-- `income_declaration` (file)
-- `address_proof` (file)
-
-**Requirements:**
-
-- Upload for ALL legal representatives
-- Max 25 MB per file
-- Formats: PDF, JPEG, JPG, PNG
-
----
-
-## Step 6: Upload Legal Person Documents[](#step-6-upload-legal-person-documents "Direct link to Step 6: Upload Legal Person Documents")
-
-`POST /users/onboarding/legal-person/{id}/documents`
-
-Upload legal person documents. Call once per document type.
-
-**Body:**
-
-- `file` (binary)
-- `type` (enum)
-
-**Required types:**
-
-- `SOCIAL_CONTRACT`
-- `BALANCE_SHEET` OR `REVENUE_STATEMENT` (at least one)
-
-**Optional:**
-
-- `KYC_AML_POLICY`
-
-**Requirements:**
-
-- Max 25 MB per file
-- Formats: PDF, JPEG, JPG, PNG
-
----
-
-## Step 7: Finalize[](#step-7-finalize "Direct link to Step 7: Finalize")
-
-`POST /users/onboarding/legal-person/{id}/finalize`
-
-Submit onboarding for processing.
-
-**Returns:** Status changes to `IN_PROCESS`
-
-**Validation:**
-
-- ✓ Onboarding exists and is in PENDING status
-- ✓ At least one shareholder created
-- ✓ At least one legal representative created
-- ✓ All legal representatives are Natural Person
-- ✓ All legal representatives linked to Natural Person shareholders
-- ✓ All legal representatives have uploaded: selfie, identity\_document, qualification\_declaration
-- ✓ Legal person has uploaded: SOCIAL\_CONTRACT
-- ✓ Legal person has uploaded: BALANCE\_SHEET or REVENUE\_STATEMENT
-- ✓ Total shareholder participation does not exceed 100%
-
-**If validation fails:** Returns `422` with error details. Fix and retry.
-
-After finalization, use the endpoint below to check the onboarding status.
-
----
-
-## Checking Status[](#checking-status "Direct link to Checking Status")
-
-`GET /users/onboarding/legal-person/{id}`
-
-Use this endpoint to check the current onboarding status.
-
-**Status flow:**
-
-```
-PENDING → IN_PROCESS → FINISHED / REJECTED / FAILED
-```
-
-Status
-
-Meaning
-
-Action
-
-`PENDING`
-
-Incomplete
-
-Complete steps 1-7
-
-`IN_PROCESS`
-
-Processing
-
-Wait
-
-`FINISHED`
-
-Approved
-
-Proceed
-
-`REJECTED`
-
-Not approved
-
-Create new onboarding
-
-`FAILED`
-
-Error
-
-Contact support
-
-**Webhooks:**
-
-If webhooks are configured, you will receive notifications for:
-
-- `FINISHED` - Onboarding approved
-- `REJECTED` - Onboarding not approved
-
-Configure webhooks to receive real-time notifications instead of polling this endpoint.
-
----
-
-## Error Handling[](#error-handling "Direct link to Error Handling")
-
-**422 on finalization:**
-
-- Response contains missing requirements
-- Fix and retry
-
-**REJECTED:**
-
-- Create new onboarding with corrected data
-
-**FAILED:**
-
-- Contact support with onboarding ID
-
-[
-
-Previous
-
-Webhooks
-
-](/baas/api-overview/webhooks)[
-
-Next
-
-Natural Person Onboarding
-
-](/baas/guides/natural-person-onboarding)
-
-- [Flow Overview](#flow-overview)
-- [Step 1: Create User Account](#step-1-create-user-account)
-- [Step 2: Create Onboarding](#step-2-create-onboarding)
-- [Step 3: Create Shareholders](#step-3-create-shareholders)
-- [Step 4: Create Legal Representatives](#step-4-create-legal-representatives)
-- [Step 5: Upload Representative Documents](#step-5-upload-representative-documents)
-- [Step 6: Upload Legal Person Documents](#step-6-upload-legal-person-documents)
-- [Step 7: Finalize](#step-7-finalize)
-- [Checking Status](#checking-status)
-- [Error Handling](#error-handling)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/overview/security",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Security | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [Overview](/overview/introduction)
-
- - [Introduction](/overview/introduction)
- - [Security](/overview/security)
- - [Environments](/overview/environments)
- - [Support](/overview/support)
-
-- [](/)
-- Overview
-- Security
-
-On this page
-
-# Security
-
-Our company's culture revolves around prioritizing security, and we have embraced a security-first approach since our inception. Our security philosophy is guided by three core principles:
-
-### Implementing Layered Defense[](#implementing-layered-defense "Direct link to Implementing Layered Defense")
-
-We employ a multi-layered defense strategy to safeguard our systems and data against external threats. This includes using firewalls, intrusion detection systems,encryption, and robust authentication mechanisms. By employing multiple layers of security measures, we create a robust barrier against potential attacks.
-
-### Mitigating Human Error[](#mitigating-human-error "Direct link to Mitigating Human Error")
-
-We recognize that humans can inadvertently introduce vulnerabilities or make mistakes that compromise security. To address this, we prioritize training and awareness programs to educate our employees about best practices and potential risks. Additionally, we implement controls and processes that minimize the impact of human errors, such as implementing access controls, regular audits, and monitoring systems.
-
-### Preventing Insider Misuse[](#preventing-insider-misuse "Direct link to Preventing Insider Misuse")
-
-While we trust our employees, we understand the importance of guarding against insider threats. We strictly control and monitor access privileges to ensure that only authorized individuals have appropriate access to sensitive information. This includes implementing role-based access controls, conducting periodic access reviews, and employing user activity monitoring to detect and prevent any unauthorized or suspicious activities.
-
-### Contact Us[](#contact-us "Direct link to Contact Us")
-
-For more information about our security measures, [contact us](/overview/support) for assistance.
-
-[
-
-Previous
-
-Introduction
-
-](/overview/introduction)[
-
-Next
-
-Environments
-
-](/overview/environments)
-
-- [Implementing Layered Defense](#implementing-layered-defense)
-- [Mitigating Human Error](#mitigating-human-error)
-- [Preventing Insider Misuse](#preventing-insider-misuse)
-- [Contact Us](#contact-us)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 20.6s)
-
-_Thinking:_
-
-**Analyzing Z.ro bank services**
-
-I need to address the user's request about Z.ro bank, which seems to offer the services we need. I’ll review their documentation to determine precisely what we should focus on. If necessary, I can ask for clarifications. I aim to assess how their offerings align with our launch requirements, checking details about authentication, webhooks, natural person onboarding, and potential subaccounts. Additionally, I should verify endpoint specifics for various functionalities like payments and onboarding merchant accounts. Using something like the OpenAPI spec might be helpful.
-
-_Thinking:_
-
-**Gathering evidence for user request**
-
-I need to gather evidence regarding Z.ro's capabilities. Using an agent might not be necessary, but it could help thoroughly analyze their documentation. For our read-only approach, I should focus on fetching information about natural person onboarding and key endpoints like authentication, webhooks, split payments, user accounts, and card issuance. I need to be careful with how I respond since the user desires clarity. My conclusion should affirm that Z.ro can likely support the regulated requirements for our launch in Brazil.
-
-_Thinking:_
-
-**Defining project requirements**
-
-I need to build a commission engine, ledger, employer/employee product, payout policy logic, integrations, support operations, and legal design. For detailed vendor coverage, it's essential to contract with a BaaS API for functionalities like subaccounts, onboarding, bank/wallet accounts, and handling Pix transactions, among other features. I should also consider a PaaS API if we only need Pix without complete account onboarding. Ultimately, I need to decide what exactly we'll require from Z.ro and think this through carefully.
-
-_Thinking:_
-
-**Gathering onboarding specifics**
-
-I need to fetch various details related to environments, authentication protocols, idempotence, webhooks, and onboarding for both natural and legal persons. It’s crucial to understand the exact signup flow and relevant endpoint specifics, especially for authentication—which uses API ID/Key to obtain a JWT bearer. I should also look into headers, signatures, and request IDs. Let’s grab documents on auth, protocol, webhooks, and the natural person onboarding guide while we're at it.
-
-Checking the integration mechanics now: auth, webhook model, KYC/KYB flows, and whether their Pix split / account structure matches our commission flow or if we still need our own internal ledger.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/guides/natural-person-onboarding",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Natural Person Onboarding | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
- - [Legal Person Onboarding](/baas/guides/legal-person-onboarding)
- - [Natural Person Onboarding](/baas/guides/natural-person-onboarding)
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- Guides
-- Natural Person Onboarding
-
-On this page
-
-# Natural Person Onboarding
-
-Complete flow for onboarding a Natural Person through the BaaS API.
-
-## Flow Overview[](#flow-overview "Direct link to Flow Overview")
-
-Execute steps 1-3 in order. Step 4 is for checking the result.
-
----
-
-## Step 1: Create User Account[](#step-1-create-user-account "Direct link to Step 1: Create User Account")
-
-`POST /users/accounts`
-
-Create user account as Natural Person with CPF.
-
-**Returns:** `user_id`
-
----
-
-## Step 2: Create Onboarding[](#step-2-create-onboarding "Direct link to Step 2: Create Onboarding")
-
-`POST /users/onboardings`
-
-Create onboarding record with user address and personal data.
-
-**Returns:** `onboarding_id` → Save for Steps 3 and 4
-
-**Body (required):**
-
-- `address` (object): `zip_code`, `street`, `number`, `city`, `federative_unit`, `country` (required); `neighborhood`, `complement` (optional)
-- `nationality` (string)
-- `pep` (boolean)
-
-**Body (optional):**
-
-- `pep_since` (date, format: `YYYY-MM-DD`)
-- `occupation_cbo_code` (number)
-- `occupation_income` (number, R$ cents)
-- `patrimony` (number, R$ cents)
-
-**Note:** Cannot create if user has active onboarding (PENDING, FINISHED). Can create new if previous was REJECTED or FAILED.
-
----
-
-## Step 3: Upload Documents[](#step-3-upload-documents "Direct link to Step 3: Upload Documents")
-
-`POST /users/onboardings/{id}/documents`
-
-Upload documents (multipart/form-data). Two methods available:
-
-**Method A — Physical document:**
-
-- `selfie` (file, required)
-- `document_front` (file, required)
-- `document_back` (file, required)
-- `document_file_type` (enum: `rg`, `cnh`, required)
-
-**Method B — Digital identity:**
-
-- `selfie` (file, required)
-- `document_id` (string, required)
-
-**Optional:**
-
-- `address_proof` (file)
-
-**Requirements:**
-
-- Max 25 MB per file
-- Choose one method (A or B), not both
-
----
-
-## Step 4: Check Status[](#step-4-check-status "Direct link to Step 4: Check Status")
-
-`GET /users/onboardings/{id}`
-
-Use this endpoint to check the current onboarding status.
-
-**Status flow:**
-
-```
-PENDING → FINISHED / REJECTED / FAILED
-```
-
-Status
-
-Meaning
-
-Action
-
-`PENDING`
-
-Awaiting documents or processing
-
-Complete step 3 or wait
-
-`FINISHED`
-
-Approved
-
-Proceed
-
-`REJECTED`
-
-Not approved
-
-Create new onboarding
-
-`FAILED`
-
-Error
-
-Contact support
-
-**Webhooks:**
-
-If webhooks are configured, you will receive notifications for:
-
-- `FINISHED` - Onboarding approved
-- `REJECTED` - Onboarding not approved
-
-Configure webhooks to receive real-time notifications instead of polling this endpoint.
-
----
-
-## Error Handling[](#error-handling "Direct link to Error Handling")
-
-**REJECTED:**
-
-- Create new onboarding with corrected data
-
-**FAILED:**
-
-- Contact support with onboarding ID
-
-[
-
-Previous
-
-Legal Person Onboarding
-
-](/baas/guides/legal-person-onboarding)[
-
-Next
-
-Introduction
-
-](/baas/endpoints/zro-global-baas-api)
-
-- [Flow Overview](#flow-overview)
-- [Step 1: Create User Account](#step-1-create-user-account)
-- [Step 2: Create Onboarding](#step-2-create-onboarding)
-- [Step 3: Upload Documents](#step-3-upload-documents)
-- [Step 4: Check Status](#step-4-check-status)
-- [Error Handling](#error-handling)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/api-overview/authentication",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Authentication | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
- - [Introduction](/baas/api-overview/introduction)
- - [Authentication](/baas/api-overview/authentication)
- - [Protocol](/baas/api-overview/protocol)
- - [Idempotence](/baas/api-overview/idempotence)
- - [Rate Limiting](/baas/api-overview/rate-limiting)
- - [Request ID (Nonce)](/baas/api-overview/request-id)
- - [Serialization](/baas/api-overview/serialization)
- - [Replay Protection](/baas/api-overview/replay)
- - [Pagination](/baas/api-overview/pagination)
- - [API Responses](/baas/api-overview/api-responses)
- - [Changelog](/baas/api-overview/changelog)
- - [Webhooks](/baas/api-overview/webhooks)
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- API Overview
-- Authentication
-
-On this page
-
-# Authentication
-
-All API requests require HTTP Bearer Authentication security authentication through an **Access Token**.
-
-It is important to note that all API requests must be made via HTTPS, as calls made by simple HTTP will not be accepted. In addition, it is essential that API requests be authenticated, otherwise they will not be successfully executed.
-
-## How to generate a new Access Token?[](#how-to-generate-a-new-access-token "Direct link to How to generate a new Access Token?")
-
-**[To generate a new Access Token](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)**, simply provide your `API ID` and `API Key` in the request body of the `/auth/signin` endpoint. This request will return an Access Token, which is precisely the Bearer Token required for authentication of all requests.
-
-info
-
-If your Access Token stops working or you have accidentally shared it, insert it into the ["Refresh token"](/baas/endpoints/v-1-refresh-token-auth-rest-controller-execute-v-1) endpoint and a new valid Access Token will be returned, ready to be used.
-
-[
-
-Previous
-
-Introduction
-
-](/baas/api-overview/introduction)[
-
-Next
-
-Protocol
-
-](/baas/api-overview/protocol)
-
-- [How to generate a new Access Token?](#how-to-generate-a-new-access-token)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/api-overview/webhooks",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Webhooks | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
- - [Introduction](/baas/api-overview/introduction)
- - [Authentication](/baas/api-overview/authentication)
- - [Protocol](/baas/api-overview/protocol)
- - [Idempotence](/baas/api-overview/idempotence)
- - [Rate Limiting](/baas/api-overview/rate-limiting)
- - [Request ID (Nonce)](/baas/api-overview/request-id)
- - [Serialization](/baas/api-overview/serialization)
- - [Replay Protection](/baas/api-overview/replay)
- - [Pagination](/baas/api-overview/pagination)
- - [API Responses](/baas/api-overview/api-responses)
- - [Changelog](/baas/api-overview/changelog)
- - [Webhooks](/baas/api-overview/webhooks)
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- API Overview
-- Webhooks
-
-On this page
-
-# Webhooks
-
-Your account can be configured so that when certain events occur on your account, a HTTP POST request containing JSON data pertaining to that event is sent to one or more URLs of your choosing. These URLs can be configured inside your settings making a request to our team. Notifications of all events listed below are sent to all the configured URLs.
-
-
-
-## Types of webhooks[](#types-of-webhooks "Direct link to Types of webhooks")
-
-Type
-
-Description
-
-PAYMENT
-
-When you send a pix payment.
-
-PAYMENT FAILED
-
-When you send a pix payment and it fails.
-
-DEVOLUTION
-
-When you send a pix devolution.
-
-DEVOLUTION FAILED
-
-When you send a pix devolution and it fails.
-
-DEVOLUTION RECEIVED
-
-When receive a pix devolution.
-
-DEPOSIT
-
-When receive a pix deposit.
-
-ONBOARDING FINISHED
-
-When you create a new user onboarding and it is approved.
-
-ONBOARDING REJECTED
-
-When you create a new user onboarding and it is rejected.
-
-MERCHANT ONBOARDING KYC STATUS
-
-When merchant onboarding KYC status is updated.
-
-WALLET ACCOUNT BALANCE UPDATED
-
-When the balance is updated.
-
-JUDICIAL BLOCK ACCOUNT
-
-When a court order blocks the user's account entirely.
-
-JUDICIAL BLOCK ACCOUNT BALANCE
-
-When a court order blocks a specific amount from the user's account balance.
-
-JUDICIAL UNBLOCK ACCOUNT
-
-When a court order unblocks the user's account.
-
-JUDICIAL UNBLOCK ACCOUNT BALANCE
-
-When a court order releases a previously blocked balance amount.
-
-
-
-
-## Credentials (Not required)[](#credentials-not-required "Direct link to Credentials (Not required)")
-
-Type
-
-Description
-
-Authorization Basic
-
-base64
-
-Authorization Bearer
-
-API key or token.
-
-Signature Verification
-
-Shared secret key.
-
-Custom header
-
-Header name is not previous defined , using with api key or token.
-
-mTLS
-
-TLS certificate.
-
-
-
-
-## Payloads (Version 1)[](#payloads-version-1 "Direct link to Payloads (Version 1)")
-
-- Payment
-- Payment Failed
-- Devolution
-- Devolution Failed
-- Devolution Received
-- Deposit
-- Onboarding Finished
-- Onboarding Rejected
-- Balance updated
-- Merchant Onboarding KYC Status
-
-```
-{ "id": "4b344f93-68fb-4ddc-83b4-6288eb7c63ce", "type": "PAYMENT", "end_to_end_id": "E26264220202404171729SrlHOwU3HqB", "txid": null, "operation_id": "0f0aca83-8ea1-5ecb-9fe9-d31782ef06fb", "amount": "270", "owner_name": "Zro Bolsao", "owner_person_type": "CNPJ", "owner_document": "00000000000000", "beneficiary_name": "Name", "beneficiary_person_type": "CPF", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T17:30:00.020Z"}
-```
-
-```
-{ "id": "77198133-185e-4c08-8252-f47c9b15785b", "type": "PAYMENT", "end_to_end_id": "E26264220202404171336mckyTdpt5VZ", "txid": null, "operation_id": null, "amount": "3", "owner_name": "Zro Bolsao", "owner_person_type": "CNPJ", "owner_document": "00000000000000", "beneficiary_name": "Name", "beneficiary_person_type": "CPF", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "error_code": "NOT_ENOUGH_FUNDS", "error_description": "Não há saldo disponível.", "created_at": "2024-04-17T13:36:21.188Z"}
-```
-
-```
-{ "id": "0a1d863e-98bd-49a3-916d-840a1ec0609f", "type": "DEVOLUTION", "end_to_end_id": "D26264220202404171733p6FuxQmuCKp", "operation_id": "fbfe1a0f-011f-5edb-a01d-19e669a6d853", "amount": "270", "owner_name": "Name", "owner_document": "***000000**", "owner_bank_ispb": "26264220", "owner_bank_name": "ZRO IP S/A", "beneficiary_name": "Zro Bolsao", "beneficiary_document": "00000000000000", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T17:33:05.523Z"}
-```
-
-```
-{ "id": "0a1d863e-98bd-49a3-916d-840a1ec0609f", "type": "DEVOLUTION", "end_to_end_id": "D26264220202404171733p6FuxQmuCKp", "operation_id": null, "amount": "270", "owner_name": "Name", "owner_document": "***000000**", "owner_bank_ispb": "26264220", "owner_bank_name": "ZRO IP S/A", "beneficiary_name": "Zro Bolsao", "beneficiary_document": "00000000000000", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "error_code": "AB03", "error_description": "Liquidação da transação interrompida devido a timeout no SPI.", "created_at": "2024-04-17T17:33:05.523Z"}
-```
-
-```
-{ "id": "10b66e97-c747-4dcb-92ad-da1420a0a6b9", "type": "DEVOLUTION_RECEIVED", "end_to_end_id": "D26264220202404171733p6FuxQmuCKp", "txid": null, "operation_id": "fbfe1a0f-011f-5edb-a01d-19e669a6d853", "original_id": "4b344f93-68fb-4ddc-83b4-6288eb7c63ce", "original_end_to_end_id": "E26264220202404171729SrlHOwU3HqB", "amount": "270", "owner_name": "Name", "owner_document": "***000000**", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "beneficiary_name": "Zro Bolsao", "beneficiary_document": "00000000000000", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T17:33:05.712Z"}
-```
-
-```
-{ "id": "a839f358-0e39-409e-b9a5-5a56b18ba3f2", "type": "DEPOSIT", "end_to_end_id": "E26264220202404171333Hq7F9SWyvUE", "txid": null, "operation_id": "7da84c17-d40c-5bc1-9b69-867d1460736b", "amount": "63", "owner_name": "Zro Bolsao", "owner_document": "00000000000", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "beneficiary_name": "Name", "beneficiary_account_number": "000000", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T13:33:41.071Z"}
-```
-
-```
-{ "id": "9c4af5a2-6a6b-4e4e-8af8-e03a331b9c5a", "user_id": "c324fb70-db23-482c-a85e-ec3eb58d5941", "type": "ONBOARDING_FINISHED", "name": "John", "full_name": "John Doe", "genre": "M", "mother_name": "Jane Doe", "birth_date": "1984-11-03", "document": "11122233344", "phone_number": "5511955551234", "email": "new-user@zrobank.com.br", "active": true, "person_type": "LEGAL_PERSON", "legal_person_type": "LTDA", "address": { "zip_code": "96075858", "street": "Alameda", "number": 10, "neighborhood": "Alphaville", "city": "São Paulo", "federative_unit": "SP", "country": "Brasil", "complement": "flat 1201" }, "nationality": "Brasileiro", "pep": true, "pep_since": "2015-02-18T18:38:09.412Z", "occupation_cbo_code": 0, "occupation_income": 0, "patrimony": 1299, "failed_code": null, "failed_message": null}
-```
-
-```
-{ "id": "4b344f93-68fb-4ddc-83b4-6288eb7c63ce", "user_id": "a379d727-5409-4b9f-9cae-902aed13efcd", "type": "ONBOARDING_REJECTED", "name": "John", "full_name": "John Doe", "genre": "M", "mother_name": "Jane Doe", "birth_date": "1984-11-03", "document": "11122233344", "phone_number": "5511955551234", "email": "new-user@zrobank.com.br", "active": true, "person_type": "LEGAL_PERSON", "legal_person_type": "LTDA", "address": { "zip_code": "96075858", "street": "Alameda", "number": 10, "neighborhood": "Alphaville", "city": "São Paulo", "federative_unit": "SP", "country": "Brasil", "complement": "flat 1201" }, "nationality": "Brasileiro", "pep": true, "pep_since": "2015-02-18T18:38:09.412Z", "occupation_cbo_code": 0, "occupation_income": 0, "patrimony": 1299, "failed_code": "DOCUMENT_INVALID", "failed_message": "Failed document onboarding."}
-```
-
-```
-{ "id": "d3558873-388a-4a98-a185-578a03bce8e2", "user_id": "9d77c248-c5b5-4f6d-9d12-d1463dc49bd9", "wallet_uuid": "f08e96c8-b659-40bf-a1bd-5225ef4e5632", "wallet_name": "DEFAULT", "operation_id": "cb835846-47b2-4bad-abd3-56e8b0d65ffe", "type": "WALLET_ACCOUNT_BALANCE_UPDATED", "action": "credit", "value": 100, "old_balance": 1000, "new_balance": 1100, "created_at": "2024-06-20T12:34:56.071Z"}
-```
-
-> `action` possible values: `credit` or `debit`.
-
-```
-{ "slug_merchant": "0897A2E2022D4B68AD15DB6204C11BE7", "document_id": "12345678000195", "dt_insert": "2025-02-04T10:30:00Z", "risk_analysis_status": "PENDING", "dt_risk_analysis_status": "2025-02-04T12:00:00Z", "risk_analysis_status_justification": "Documents pending for risk review"}
-```
-
-## Payloads (Version 2)[](#payloads-version-2 "Direct link to Payloads (Version 2)")
-
-- Devolution Received
-- Deposit
-- Payment Failed
-- Devolution Failed
-
-```
-{ "id": "10b66e97-c747-4dcb-92ad-da1420a0a6b9", "type": "DEVOLUTION_RECEIVED", "end_to_end_id": "D26264220202404171733p6FuxQmuCKp", "txid": null, "operation_id": "fbfe1a0f-011f-5edb-a01d-19e669a6d853", "original_id": "4b344f93-68fb-4ddc-83b4-6288eb7c63ce", "original_end_to_end_id": "E26264220202404171729SrlHOwU3HqB", "amount": "270", "owner_name": "Name", "owner_document": "***000000**", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "beneficiary_name": "Name", "beneficiary_account_number": "000000", "beneficiary_branch_number": "0000", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T17:33:05.712Z"}
-```
-
-```
-{ "id": "a839f358-0e39-409e-b9a5-5a56b18ba3f2", "type": "DEPOSIT", "end_to_end_id": "E26264220202404171333Hq7F9SWyvUE", "txid": null, "operation_id": "7da84c17-d40c-5bc1-9b69-867d1460736b", "amount": "63", "owner_name": "Zro Bolsao", "owner_document": "00000000000", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "beneficiary_name": "Name", "beneficiary_account_number": "000000", "beneficiary_branch_number": "0000", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T13:33:41.071Z"}
-```
-
-```
-{ "id": "77198133-185e-4c08-8252-f47c9b15785b", "type": "PAYMENT_FAILED", "end_to_end_id": "E26264220202404171336mckyTdpt5VZ", "txid": null, "operation_id": null, "amount": "3", "owner_name": "Zro Bolsao", "owner_person_type": "CNPJ", "owner_document": "00000000000000", "beneficiary_name": "Name", "beneficiary_person_type": "CPF", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "error_code": "NOT_ENOUGH_FUNDS", "error_description": "Não há saldo disponível.", "created_at": "2024-04-17T13:36:21.188Z"}
-```
-
-```
-{ "id": "0a1d863e-98bd-49a3-916d-840a1ec0609f", "type": "DEVOLUTION_FAILED", "end_to_end_id": "D26264220202404171733p6FuxQmuCKp", "operation_id": null, "amount": "270", "owner_name": "Name", "owner_document": "***000000**", "owner_bank_ispb": "26264220", "owner_bank_name": "ZRO IP S/A", "beneficiary_name": "Zro Bolsao", "beneficiary_document": "00000000000000", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "error_code": "AB03", "error_description": "Liquidação da transação interrompida devido a timeout no SPI.", "created_at": "2024-04-17T17:33:05.523Z"}
-```
-
-## Payloads (Version 3)[](#payloads-version-3 "Direct link to Payloads (Version 3)")
-
-- Deposit
-- Payment Failed
-
-```
-{ "id": "a839f358-0e39-409e-b9a5-5a56b18ba3f2", "type": "DEPOSIT", "end_to_end_id": "E26264220202404171333Hq7F9SWyvUE", "txid": null, "operation_id": "7da84c17-d40c-5bc1-9b69-867d1460736b", "amount": "63", "owner_name": "Zro Bolsao", "owner_document": "00000000000", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "owner_branch_number": "0000", "owner_account_number": "000000", "beneficiary_name": "Name", "beneficiary_account_number": "000000", "beneficiary_branch_number": "0000", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T13:33:41.071Z"}
-```
-
-```
-{ "id": "77198133-185e-4c08-8252-f47c9b15785b", "type": "PAYMENT_FAILED", "end_to_end_id": "E26264220202404171336mckyTdpt5VZ", "txid": null, "operation_id": null, "amount": "3", "owner_name": "Zro Bolsao", "owner_person_type": "CNPJ", "owner_document": "00000000000000", "beneficiary_name": "Name", "beneficiary_person_type": "CPF", "beneficiary_document": "***000000**", "beneficiary_account_type": "CACC", "beneficiary_account_number": "000000", "beneficiary_branch_number": "0000", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "error_code": "NOT_ENOUGH_FUNDS", "error_description": "Não há saldo disponível.", "created_at": "2024-04-17T13:36:21.188Z"}
-```
-
-## Payloads (Version 4)[](#payloads-version-4 "Direct link to Payloads (Version 4)")
-
-- Deposit
-
-```
-{ "id": "a839f358-0e39-409e-b9a5-5a56b18ba3f2", "type": "DEPOSIT", "end_to_end_id": "E26264220202404171333Hq7F9SWyvUE", "txid": null, "operation_id": "7da84c17-d40c-5bc1-9b69-867d1460736b", "amount": "63", "owner_name": "Zro Bolsao", "owner_document": "00000000000", "owner_bank_name": "ZRO IP S/A", "owner_bank_ispb": "26264220", "owner_branch_number": "0000", "owner_account_number": "000000", "owner_account_type": "CACC", "beneficiary_name": "Name", "beneficiary_account_number": "000000", "beneficiary_branch_number": "0000", "beneficiary_document": "***000000**", "beneficiary_bank_name": "ZRO IP S/A", "beneficiary_bank_ispb": "26264220", "created_at": "2024-04-17T13:33:41.071Z"}
-```
-
-## Judicial Webhooks[](#judicial-webhooks "Direct link to Judicial Webhooks")
-
-Judicial webhooks are triggered by court-ordered operations on user accounts. You can register multiple URLs for the same event type — all registered URLs will receive the notification independently. This is useful if you operate multiple products (e.g., PaaS and Gateway) and need each one to receive the event.
-
-### Payloads (Version 1)[](#payloads-version-1-1 "Direct link to Payloads (Version 1)")
-
-- Judicial Block Account
-- Judicial Block Account Balance
-- Judicial Unblock Account
-- Judicial Unblock Account Balance
-
-Triggered when a court order blocks the user's account entirely.
-
-```
-{ "idJudicialBlockAccount": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "userId": "9d77c248-c5b5-4f6d-9d12-d1463dc49bd9", "accountNumber": "000001", "branchNumber": "0001", "processNumber": "0001234-56.2026.8.26.0100", "courtName": "1ª Vara Cível de São Paulo", "createdAt": "2024-04-17T17:30:00.020Z"}
-```
-
-> `processNumber` and `courtName` are optional — they are only present when provided in the court order.
-
-Triggered when a court order blocks a specific amount from the user's account balance. The `requestedAmount` field is included only when provided by the court order.
-
-```
-{ "idJudicialBlockAccount": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "userId": "9d77c248-c5b5-4f6d-9d12-d1463dc49bd9", "accountNumber": "000001", "branchNumber": "0001", "isTotalValue": false, "requestedAmount": 150000, "processNumber": "0001234-56.2026.8.26.0100", "courtName": "1ª Vara Cível de São Paulo", "createdAt": "2024-04-17T17:30:00.020Z"}
-```
-
-> When `isTotalValue` is `true`, the entire available balance is blocked. `requestedAmount` is optional and only present when informed in the court order. `processNumber` and `courtName` are also optional.
-
-Triggered when a court order lifts a full account block.
-
-```
-{ "idJudicialUnblockAccount": "c3e9b7f1-12ab-4d88-9e4f-1a2b3c4d5e6f", "userId": "9d77c248-c5b5-4f6d-9d12-d1463dc49bd9", "accountNumber": "000001", "branchNumber": "0001", "processNumber": "0001234-56.2026.8.26.0100", "courtName": "1ª Vara Cível de São Paulo", "createdAt": "2024-04-17T17:35:00.020Z"}
-```
-
-> `processNumber` and `courtName` are optional — they are only present when provided in the court order.
-
-Triggered when a court order releases a previously blocked balance amount.
-
-```
-{ "idJudicialUnblockAccount": "c3e9b7f1-12ab-4d88-9e4f-1a2b3c4d5e6f", "userId": "9d77c248-c5b5-4f6d-9d12-d1463dc49bd9", "blockAccountBalanceId": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "accountNumber": "000001", "branchNumber": "0001", "processNumber": "0001234-56.2026.8.26.0100", "courtName": "1ª Vara Cível de São Paulo", "requestedAmount": 150000, "createdAt": "2024-04-17T17:35:00.020Z"}
-```
-
-> `blockAccountBalanceId` references the original `JUDICIAL_BLOCK_ACCOUNT_BALANCE` event that is being released.
-
-[
-
-Previous
-
-Changelog
-
-](/baas/api-overview/changelog)[
-
-Next
-
-Legal Person Onboarding
-
-](/baas/guides/legal-person-onboarding)
-
-- [Types of webhooks](#types-of-webhooks)
-- [Credentials (Not required)](#credentials-not-required)
-- [Payloads (Version 1)](#payloads-version-1)
-- [Payloads (Version 2)](#payloads-version-2)
-- [Payloads (Version 3)](#payloads-version-3)
-- [Payloads (Version 4)](#payloads-version-4)
-- [Judicial Webhooks](#judicial-webhooks)
- - [Payloads (Version 1)](#payloads-version-1-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/paas/endpoints/create-split-pix-qr-code-static-rest-controller-execute",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Create Split PIX QR Code Static | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/paas/api-overview/introduction)
-
-- [Endpoints](/paas/endpoints/zro-global-paas-api)
-
- - [Introduction](/paas/endpoints/zro-global-paas-api)
- - [Authentication](/paas/endpoints/login-auth-rest-controller-execute)
-
- - [Pix | Keys](/paas/endpoints/get-all-pix-key-rest-controller-execute)
-
- - [Pix | Keys | Dynamic QR Code](/paas/endpoints/create-qr-code-dynamic-instant-billing-rest-controller-execute)
-
- - [Pix | Keys | Static QR Code](/paas/endpoints/get-all-qr-code-static-rest-controller-execute)
-
- - [Split Payments](/paas/endpoints/create-split-pix-qr-code-static-rest-controller-execute)
-
- - [Create Split PIX QR Code Static](/paas/endpoints/create-split-pix-qr-code-static-rest-controller-execute)
- - [Pix | Payments](/paas/endpoints/v-2-create-decoded-qr-code-rest-controller-execute-v-2)
-
- - [Pix | Devolutions](/paas/endpoints/create-pix-devolution-rest-controller-execute)
-
- - [Pix | Deposits](/paas/endpoints/v-5-get-all-pix-deposit-rest-controller-execute-v-5)
-
- - [Otc | Conversions](/paas/endpoints/v-2-create-conversion-rest-controller-execute-v-2)
-
- - [Quotations | Conversions](/paas/endpoints/v-2-get-quotation-rest-controller-execute-v-2)
-
- - [Operations | Wallets](/paas/endpoints/get-all-wallet-rest-controller-execute)
-
- - [Operations | P2P Transfers](/paas/endpoints/create-p-2-p-transfer-rest-controller-execute)
-
- - [Operations | Wallet Accounts](/paas/endpoints/get-all-wallet-account-rest-controller-execute)
-
- - [Operations | Currency](/paas/endpoints/get-all-currency-rest-controller-execute)
-
- - [Operations | Operation](/paas/endpoints/get-all-operations-rest-controller-execute)
-
- - [Operations | Wallet limits](/paas/endpoints/update-wallet-limit-rest-controller-execute)
-
- - [Banking](/paas/endpoints/v-2-get-all-banking-ted-received-rest-controller-execute-v-2)
-
- - [Banking | Bank Billet | Pix Deposits](/paas/endpoints/create-banking-billet-pix-deposit-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Template](/paas/endpoints/create-banking-billet-pix-deposit-template-rest-controller-execute)
-
- - [Banking | Bank Billet | Payments](/paas/endpoints/get-banking-billet-payment-by-id-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/paas/endpoints/create-banking-billet-pix-deposit-batch-rest-controller-execute)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/paas/endpoints/create-banking-billet-pix-deposit-batch-item-rest-controller-execute)
-
- - [Utils | User Withdraw Settings](/paas/endpoints/get-all-user-withdraw-setting-rest-controller-execute)
-
- - [Health](/paas/endpoints/health-controller-execute)
-
- - [Reports](/paas/endpoints/v-5-generate-pix-statement-export-rest-controller-execute-v-5)
-
- - [Storage](/paas/endpoints/get-all-files-rest-controller-execute)
-
- - [Users | User Bank Account](/paas/endpoints/get-user-bank-account-by-wallet-rest-controller-execute)
-
- - [Pix | Recurrence](/paas/endpoints/create-pix-recurrence-rest-controller-execute)
-
- - [Pix | Scheduled Payments](/paas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute)
-
- - [Pix | Automatic Receiver Limits](/paas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute)
-
- - [Card](/paas/endpoints/create-virtual-card-rest-controller-execute)
-
- - [Card | Onboarding](/paas/endpoints/get-terms-of-use-rest-controller-execute)
-
- - [Open Finance | Participants](/paas/endpoints/get-all-open-finance-participants-rest-controller-execute)
-
- - [Open Finance | Payment Consents](/paas/endpoints/create-open-finance-payment-consent-by-pix-key-rest-controller-execute)
-
- - [Open Finance | Payments](/paas/endpoints/create-open-finance-payment-rest-controller-execute)
-
- - [Schemas](/paas/endpoints/schemas/authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Split Payments
-- Create Split PIX QR Code Static
-
-# Create Split PIX QR Code Static
-
-POST
-
-## /split-payments/pix/qr-codes/static
-
-**Tag**: api-paas-post-split-payments-pix-qr-codes-static**Description**: Generate a new static QR Code with split payment configuration.
-
-## Request[](#request "Direct link to Request")
-
-### Header Parameters
-
-**x-include-replay-protection-schema** string
-
-The replay-protection-schema allows the user to choose between 3 options:
-
-- If there's no value: The default protection checks that the values in this request are equal: **{ method, params, path, query, body, userId }.** This means that if a request repeats the same values, it will be blocked.
-- 'nonce': The nonce and **{ method, params, path, query, body, userId }** value are checked. When the protection schema is this, requests will be OK if this nonce value is different in each request.
-- 'x-transaction-uuid': The transactionId and **{ method, params, path, query, body, userId }** value are checked. Requests will be OK if this x-transaction-uuid value is different in each request.
-- 'x-transaction-uuid&nonce' or 'nonce&x-transaction-uuid': The nonce, transactionId value and **{ method, params, path, query, body, userId }** are checked, i.e. if requests are repeated the same value in both fields, they will be blocked. But if any field has a different value, the request is OK.
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**x-transaction-uuid** stringrequired
-
-The transaction ID is a UUID (v4) used to uniquely identify the object that will be created. All objects must have an identifier.
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-- application/json
-
-### Body
-
-**required**
-
-**key\_id** stringrequired
-
-Associated key ID.
-
-**value** numberrequired
-
-Value in R$ cents.
-
-**summary** string
-
-User friendly static QR Code identifier.
-
-**description** string
-
-User defined payment description.
-
-**expiration\_date** date-time
-
-Expiration date to pay static QR Code. **Max date is 3 months ahead.**
-
-**payable\_many\_times** boolean
-
-If it is true, static QR Code can be paid many times. **When it is false, expiration date is required.**
-
-**merchant\_id** string
-
-User defined payment merchant ID.
-
-**split** objectrequired
-
-**split\_type** stringrequired
-
-**Possible values:** \[`PERCENTUAL`, `ABSOLUTE`\]
-
-Split type (PERCENTUAL or ABSOLUTE).
-
-**accounts** object\[\]required
-
-Array of accounts to receive split payments.
-
-- Array \[
-
-
-**person\_type** stringrequired
-
-**Possible values:** \[`NATURAL_PERSON`, `LEGAL_PERSON`\]
-
-Person type (NATURAL\_PERSON or LEGAL\_PERSON).
-
-**name** stringrequired
-
-Name of the account holder.
-
-**document** stringrequired
-
-CPF or CNPJ of the account holder.
-
-**bank\_ispb** stringrequired
-
-Bank ISPB code.
-
-**branch** stringrequired
-
-Branch number.
-
-**account\_number** stringrequired
-
-Account number.
-
-**account\_type** stringrequired
-
-**Possible values:** \[`CACC`, `CASH`, `CHAR`, `CISH`, `COMM`, `CPAC`, `LLSV`, `LOAN`, `MGLD`, `MOMA`, `NREX`, `ODFT`, `ONDP`, `OTHR`, `SACC`, `SLRY`, `SVGS`, `TAXE`, `TRAN`, `TRAS`, `CC`, `PG`, `CD`, `CG`, `CI`, `PP`\]
-
-Account type.
-
-**split\_value** numberrequired
-
-Split value. For PERCENTUAL: percentage (0-100). For ABSOLUTE: value in cents.
-
-- \]
-
-
-## Responses[](#responses "Direct link to Responses")
-
-- 201
-- 400
-- 401
-- 422
-
-The split QR Code returned successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-Split QR Code ID.
-
-**key\_id** stringrequired
-
-Associated key ID.
-
-**state** stringrequired
-
-**Possible values:** \[`PENDING`, `READY`, `ERROR`\]
-
-Split QR Code state.
-
-**summary** string
-
-User defined payment ID.
-
-**description** string
-
-User defined payment description.
-
-**expiration\_date** date-time
-
-Expiration date to pay static QR Code. **When it is false, expiration date is required.**
-
-**created\_at** date-timerequired
-
-Split QR Code created at.
-
-```
-{ "id": "9a1c2d3e-4f56-4789-8abc-def012345678", "key_id": "f6e2e084-29b9-4935-a059-5473b13033aa", "state": "PENDING", "summary": "party-payment", "description": "User defined description", "expiration_date": "2026-04-05T13:55:25.556Z", "created_at": "2026-04-05T13:55:25.556Z"}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Delete Static QR Code
-
-](/paas/endpoints/delete-by-qr-code-static-id-rest-controller-execute)[
-
-Next
-
-Create Decoded QR Code
-
-](/paas/endpoints/v-2-create-decoded-qr-code-rest-controller-execute-v-2)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 18.7s)
-
-_Thinking:_
-
-**Evaluating BaaS and PaaS options**
-
-I’m considering how to approach the user's request. We can read documentation pages individually or potentially fetch JSONs. Using webfetch or bash could work. The focus seems to be on understanding whether a BaaS (Backend as a Service) or PaaS (Platform as a Service) is the correct choice for onboarding end users and managing wallets.
-
-It looks like BaaS might be the better option, offering features like onboarding, wallets, and user accounts. PaaS might be more limited in that sense.
-
-_Thinking:_
-
-**Investigating BaaS features**
-
-I need to explore the differences regarding `x-product-uuid` for targeting users. It seems that BaaS allows platforms to operate on users' behalf within products. I might have to understand features like subaccounts, backoffice, and white-label aspects from the website. I wonder if Bely requires configuration through a team instead of an API. I should also inspect the BaaS endpoint documentation to clarify details about user accounts, wallet accounts, and whether employees receive bank accounts or cards.
-
-_Thinking:_
-
-**Inspecting support requirements**
-
-I’m thinking that it could be important to ensure that production URLs have the right support. I should confirm the support email and the registration process through the Google Form. Also, it seems there’s no mention of self-service webhook configuration, which I’ll need to request from the team. That definitely feels like a concrete requirement. I’ll take a closer look at the support page to clarify everything.
-
-One more pass on operational details: production access, support path, environment model, and a few user/wallet/card endpoints that affect the exact launch integration shape.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/overview/environments",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Environments | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [Overview](/overview/introduction)
-
- - [Introduction](/overview/introduction)
- - [Security](/overview/security)
- - [Environments](/overview/environments)
- - [Support](/overview/support)
-
-- [](/)
-- Overview
-- Environments
-
-On this page
-
-# Environments
-
-We offer two environments for our API: **Sandbox** and **Production**
-
-## Sandbox Environment[](#sandbox-environment "Direct link to Sandbox Environment")
-
-The Sandbox Environment is designed for integration testing, experimentation, and development purposes. It allows you to test and validate your integrations without affecting your production systems or data.
-
-## Production Environment[](#production-environment "Direct link to Production Environment")
-
-The Production Environment is the live environment where your application interacts with our API in a production-ready manner. It provides stable and secure access to real-time data.
-
-## Contact us[](#contact-us "Direct link to Contact us")
-
-For further information, assistance regarding both environments and pricing details, please contact our [support team](/overview/support)
-
-[
-
-Previous
-
-Security
-
-](/overview/security)[
-
-Next
-
-Support
-
-](/overview/support)
-
-- [Sandbox Environment](#sandbox-environment)
-- [Production Environment](#production-environment)
-- [Contact us](#contact-us)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/overview/support",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Support | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [Overview](/overview/introduction)
-
- - [Introduction](/overview/introduction)
- - [Security](/overview/security)
- - [Environments](/overview/environments)
- - [Support](/overview/support)
-
-- [](/)
-- Overview
-- Support
-
-# Support
-
-It’s always a pleasure to help you! If you require assistance with the integration or have any questions, please feel free to use our documentation and do not hesitate to contact us by:
-
-- Support Email: [meajuda@zrobank.com.br](mailto:meajuda@zrobank.com.br)
-
-If you have a commercial request or issue, please contact us by:
-
-- Commercial Email: [comercial@zrobank.com.br](mailto:comercial@zrobank.com.br)
-
-[
-
-Previous
-
-Environments
-
-](/overview/environments)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Create Virtual Card | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Create Virtual Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
- - [List all cards](/baas/endpoints/v-1-get-all-cards-rest-controller-execute-v-1)
- - [Unblock Card](/baas/endpoints/v-1-unblock-card-rest-controller-execute-v-1)
- - [Block Card](/baas/endpoints/v-1-block-card-rest-controller-execute-v-1)
- - [Card details](/baas/endpoints/v-1-card-details-rest-controller-execute-v-1)
- - [Cancel Card](/baas/endpoints/v-1-cancel-card-rest-controller-execute-v-1)
- - [Create Physical Card](/baas/endpoints/v-1-create-physical-card-rest-controller-execute-v-1)
- - [Activate Card](/baas/endpoints/v-1-activate-card-rest-controller-execute-v-1)
- - [Issue a Replacement Physical Card](/baas/endpoints/v-1-create-new-physical-card-via-rest-controller-execute-v-1)
- - [Change Card Password](/baas/endpoints/v-1-change-card-password-rest-controller-execute-v-1)
- - [Get Card Tracking](/baas/endpoints/v-1-get-card-tracking-rest-controller-execute-v-1)
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Card
-- Create Virtual Card
-
-# Create Virtual Card
-
-POST
-
-## /v1/cards/virtual
-
-**Tag**: api-baas-post-virtual-card**Description**: Create a new virtual card.
-
-## Request[](#request "Direct link to Request")
-
-### Header Parameters
-
-**x-transaction-uuid** stringrequired
-
-The transaction ID is a UUID (v4) used to uniquely identify the object that will be created. All objects must have an identifier.
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 201
-- 400
-- 401
-- 422
-
-Virtual card created.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-Card ID.
-
-**is\_virtual** booleanrequired
-
-Is Virtual Card.
-
-**status** stringrequired
-
-**Possible values:** \[`password_locked`, `activated`, `pending`, `blocked`, `cancelled`, `preventive_blocked`\]
-
-Card Status.
-
-```
-{ "id": "f6e2e084-29b9-4935-a059-5473b13033aa", "is_virtual": true, "status": "blocked"}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Get Company Registration by ID.
-
-](/baas/endpoints/v-1-get-company-registration-by-id-rest-controller-execute-v-1)[
-
-Next
-
-List all cards
-
-](/baas/endpoints/v-1-get-all-cards-rest-controller-execute-v-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- List User Bank Account | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [List User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Users | User Bank Account
-- List User Bank Account
-
-# List User Bank Account
-
-GET
-
-## /v1/users/banking/accounts
-
-Retrieve a user bank account.
-
-## Request[](#request "Direct link to Request")
-
-### Header Parameters
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 200
-- 400
-- 401
-- 422
-
-The user bank account returned successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-User bank account ID.
-
-**user\_id** stringrequired
-
-User UUID.
-
-**user\_document** stringrequired
-
-User document.
-
-**onboarding\_id** stringrequired
-
-Onboarding UUID.
-
-**account\_number** stringrequired
-
-Account number.
-
-**branch\_number** stringrequired
-
-Branch number.
-
-**active** booleanrequired
-
-User bank account is active.
-
-**default** booleanrequired
-
-User bank account default flag.
-
-**created\_at** date-timerequired
-
-User bank account created at.
-
-```
-{ "id": "f6e2e084-29b9-4935-a059-5473b13033aa", "user_id": "caff7d9f-b554-4978-b87d-717a4115a7a8", "user_document": "84411010003", "onboarding_id": "79ffc231-d5b5-4e84-9384-4b9ce5d36a9c", "account_number": "123456", "branch_number": "0001", "active": true, "default": false, "created_at": "2026-03-26T14:02:59.126Z"}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Update User Account by ID
-
-](/baas/endpoints/v-2-update-user-account-rest-controller-execute-v-2)[
-
-Next
-
-List Legal Person Onboardings
-
-](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 57.2s)
-
-_Thinking:_
-
-**Verifying onboarding details**
-
-I need to consider using webfetch for certain endpoints to confirm if merchant onboarding exists, especially for split and card onboarding. It feels like I might require more details on the merchant onboarding process. I wonder if I have enough information already. I guess when I think about “exactly what we need,” it really means having all the required information from our side to get started. So, let's ensure I get that clarified!
-
-_Thinking:_
-
-**Creating an onboarding checklist**
-
-I think we should create a detailed checklist for our processes. For commercial and contracting steps, I need to register the company for BaaS and PaaS API using a Google form, obtain API ID and key for both sandbox and production, and define product details and webhook URLs. I also need to confirm pricing and settlement models, and sign necessary agreements.
-
-For employer and employee onboarding via BaaS, I’ll outline specific legal steps and required documents. Lastly, I need to set up financial flows, like using Pix keys for collections and payments.
-
-_Thinking:_
-
-**Evaluating banking solutions**
-
-I'm considering the need for regulated accounts and wallets for employers and employees, and it looks like BaaS will be our main focus. PaaS might suffice if we only have one master merchant, but since we need to onboard both legal and natural persons into bank-like accounts, BaaS feels necessary. We might also need Gateway for card processing and local payment methods beyond Pix. For version one, leading with a BaaS/PaaS approach, primarily using Pix for commissions, seems like a solid plan.
-
-_Thinking:_
-
-**Exploring PaaS vs. BaaS**
-
-I'm thinking about whether we really need PaaS, especially if there's a simpler solution available or if we want a split payment feature. It seems important to examine the overlap between BaaS and PaaS to avoid duplicating features. I want to ensure that we’re making the most efficient choice based on our specific needs while balancing functionality. So, I’m diving deeper to understand what each service truly brings to the table.
-
-_Thinking:_
-
-**Analyzing payment systems**
-
-I'm looking into various payment systems like Pix Keys, Payments, and Deposits. PaaS seems to have a split QR feature, while BaaS likely encompasses managed accounts and wallets. I think if we require direct splits during collection, the static split QR could work, but it's not robust enough for customizing rules like holdbacks or partial releases. Dynamic splits aren’t clear either. Our method will focus on depositing into partner accounts and calculating splits internally, so direct splits might be limited. I should consider reviewing the OpenAPI spec for specifics.
-
-_Thinking:_
-
-**Reviewing payment integration options**
-
-I think I need to consider not just documentation but also public site claims regarding local payments, including credit/debit, digital wallets, and back-office solutions. For our purposes, we’re primarily focused on local Pix and BaaS, so we might ignore crypto and cross-border options for the initial version due to regulatory complexity. It could be wise to check merchant onboarding since employers might need it to accept card payments, even if we initially integrate with their existing processors. I'll look into the merchant onboarding documentation for clarity.
-
-_Thinking:_
-
-**Clarifying payment requirements**
-
-The user asked me to review the documentation to determine our specific needs. These requirements depend on whether we're using Z.ro solely for payouts and accounts or also for payment acceptance. I think it’s important to check if there’s a Gateway or merchant onboarding option available. There’s an endpoint for merchant onboarding that I should look into. Since local payments mention cards and digital wallets, if we're processing employer customer payments through Z.ro, we would need that gateway. However, our docs suggest starting with payment-linked commission calculations while integrating with employer processors.
-
-_Thinking:_
-
-**Clarifying integration needs**
-
-I’m focusing on the integration requirements for our platform. We need to generate UUIDs per request and manage JWT token refreshes, while securely handling idempotency keys and webhooks with proper signatures. Authentication will rely on API ID/API Key, plus the nonce for endpoints. I might check the protocol/idempotence documentation for specifics. Maybe I’ll ask the user if they want to develop a launch architecture doc, but for now, I think the current details are sufficient.
-
-_Thinking:_
-
-**Detailing project requirements**
-
-I need to be precise with my final response since the user asked for exact information. So, I’ll start by stating that for our Brazil-first version, Z.ro can cover regulated custody, money movement, and onboarding, but it won’t replace our existing commission system. To get going with them, we'll need: 1) BaaS contract and credentials, 2) employer/employee onboarding data and documents, 3) Pix collection and payout integration, 4) a webhook/reconciliation layer, and 5) our own internal ledger and commission engine. Then I’ll elaborate on each point.
-
-_Thinking:_
-
-**Identifying onboarding requirements**
-
-I need to outline what we require from Z.ro for commercial access, including things like BaaS API access, potential PaaS or Gateway API access, and necessary documentation like product configuration and compliance documents.
-
-For onboarding employers, I should also gather necessary legal documents such as CNPJ, legal names, and shareholder information. Employees will need to provide personal data, CPF, and certain identification documents too. We also need to manage onboarding status and potential rejections effectively.
-
-_Thinking:_
-
-**Outlining integration requirements**
-
-I’m identifying what we need to develop or integrate on our side. This includes an onboarding UI for both employers and employees that can handle document collection. I also need to build a token/auth service for Z.ro, a webhook receiver, and systems for payout orchestration and retry handling.
-
-Additionally, I’ll focus on creating a commission rules engine, double-entry ledger, and rules for availability and holdbacks. Lastly, I'll incorporate reconciliation, analytics, customer support tools, and legal/tax policy features.
-
-_Thinking:_
-
-**Clarifying gaps before decision**
-
-I need to gather more information before making a choice. First, I want to confirm the production base URL and pricing, which aren’t public. Next, I need clarity on the settlement and custody model — specifically whether funds are in individual sub-accounts per employee or just in a master account. I also have questions about fees for onboarding and payouts, judicial block impacts, webhook security methods, and whether they can support our target verticals and risk profile.
-
-_Thinking:_
-
-**Exploring split payment options**
-
-I’m looking into whether split payments can support delayed availability or dynamic scenarios. If we're using a gateway for card acceptance, I want to understand the merchant onboarding flow and the timeline for settlement. It's probably not relevant for version 1, but I should check about data localization, audit reports, and potential KYC issues. My recommendation is to start with BaaS and possibly add PaaS split features or Gateway later, avoiding crypto for now. I’ll also fetch the merchant onboarding documentation for clarity.
-
-I’ve got enough to assess the core fit. I’m checking one last area: whether using Z.ro for customer payment acceptance would require a separate merchant/gateway track, or whether BaaS alone is enough for our recommended v1.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Create Merchant Onboarding | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Create Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
- - [List Merchants](/baas/endpoints/v-1-get-all-merchant-rest-controller-execute-v-1)
- - [Upload Merchant Onboarding Document](/baas/endpoints/v-1-upload-merchant-onboarding-document-rest-controller-execute-v-1)
- - [Get Merchant Term Acceptance](/baas/endpoints/v-1-get-merchant-term-acceptance-rest-controller-execute-v-1)
- - [Accept Merchant Term Acceptance](/baas/endpoints/v-1-accept-merchant-term-acceptance-rest-controller-execute-v-1)
- - [Get Merchant by ID](/baas/endpoints/v-1-get-merchant-by-id-rest-controller-execute-v-1)
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Users | Merchant Onboarding
-- Create Merchant Onboarding
-
-# Create Merchant Onboarding
-
-POST
-
-## /v1/users/merchant-onboarding
-
-Creates a merchant onboarding to register the legal person as a commercial establishment at Dock Acquiring. The legal person onboarding must be finished.
-
-## Request[](#request "Direct link to Request")
-
-### Header Parameters
-
-**x-transaction-uuid** stringrequired
-
-The transaction ID is a UUID (v4) used to uniquely identify the object that will be created. All objects must have an identifier.
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-- application/json
-
-### Body
-
-**required**
-
-**onboarding\_id** stringrequired
-
-Finished legal person onboarding ID.
-
-**trade\_name** stringrequired
-
-Establishment trade name. Maximum 30 characters.
-
-**mcc** stringrequired
-
-MCC (Merchant Category Code). 4 digits identifying the business type.
-
-**cnae** stringrequired
-
-CNAE code (Classificação Nacional de Atividades Econômicas).
-
-**bank\_number** stringrequired
-
-Bank number (3 digits).
-
-**bank\_branch** stringrequired
-
-Bank branch number.
-
-**bank\_branch\_check\_digit** string
-
-Bank branch check digit.
-
-**bank\_account\_number** stringrequired
-
-Bank account number.
-
-**bank\_account\_digit** stringrequired
-
-Bank account check digit.
-
-**bank\_account\_type** stringrequired
-
-**Possible values:** \[`CHECKING`, `SAVINGS`, `DEPOSIT`, `PAYMENT`\]
-
-Bank account type.
-
-**opening\_date** stringrequired
-
-Establishment opening date. Format: YYYY-MM-DD.
-
-**opening\_days** stringrequired
-
-Operating days. 7-character binary string where each position represents a day (Sun-Sat). Position 0 = Sunday, 1 = Monday, ..., 6 = Saturday. Use 1 for open, 0 for closed.
-
-**opening\_hour** stringrequired
-
-Opening hour. Format: HH:mm.
-
-**closing\_hour** stringrequired
-
-Closing hour. Format: HH:mm.
-
-**municipal\_registration** string
-
-Municipal registration number.
-
-**state\_subscription** string
-
-State registration number.
-
-**establishment\_format** stringrequired
-
-**Possible values:** \[`EI`, `MEI`, `EIRELI`, `LTDA`, `SS`, `SA`, `ME`, `EPP`, `EMPG`, `COOP`, `OTHER`\]
-
-Establishment legal format.
-
-**revenue** numberrequired
-
-Annual revenue in BRL cents.
-
-**legal\_nature\_code** stringrequired
-
-Legal nature code. Common codes:
-
-- 213-5: Empresário Individual (includes MEI)
-- 206-2: Sociedade Empresária Limitada (LTDA)
-- 232-1: Sociedade Unipessoal de Advocacia
-
-## Responses[](#responses "Direct link to Responses")
-
-- 201
-- 400
-- 401
-- 403
-- 422
-
-Merchant onboarding created successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-Merchant onboarding ID.
-
-**status** stringrequired
-
-**Possible values:** \[`PENDING`, `WAITING_DOCUMENTS`, `APPROVED`, `DECLINED`, `FAILED`\]
-
-Merchant onboarding status.
-
-**external\_id** string
-
-Merchant external identifier.
-
-**created\_at** date-timerequired
-
-Created at timestamp.
-
-```
-{ "id": "8fc58500-b12e-49d7-892c-dfd704b94c2d", "status": "PENDING", "external_id": "ABC123DEF456", "created_at": "2024-01-15T10:00:00.000Z"}
-```
-
-If any required parameter is missing or has invalid format/type.
-
-User authentication failed.
-
-User does not have permission to access this resource.
-
-If any required parameter is missing or has invalid format/type.
-
-Loading...
-
-[
-
-Previous
-
-Update Shareholder
-
-](/baas/endpoints/v-1-update-shareholder-rest-controller-execute-v-1)[
-
-Next
-
-List Merchants
-
-](/baas/endpoints/v-1-get-all-merchant-rest-controller-execute-v-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/gateway/api-overview/how-to-use",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- How to use | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/gateway/api-overview/introduction)
-
- - [Introduction](/gateway/api-overview/introduction)
- - [Authentication](/gateway/api-overview/authentication)
- - [Protocol](/gateway/api-overview/protocol)
- - [Serialization](/gateway/api-overview/serialization)
- - [Errors](/gateway/api-overview/errors)
- - [How to use](/gateway/api-overview/how-to-use)
- - [API Responses](/gateway/api-overview/api-responses)
- - [Duplication Prevention](/gateway/api-overview/duplication-prevention)
- - [Changelog](/gateway/api-overview/changelog)
- - [Webhooks](/gateway/api-overview/webhooks)
-- [Endpoints](/gateway/endpoints/zrobank)
-
-
-- [](/)
-- API Overview
-- How to use
-
-On this page
-
-# How to use
-
-## Customer Bank Account Registration[](#customer-bank-account-registration "Direct link to Customer Bank Account Registration")
-
-The Zro Gateway has a feature that limits the bank accounts authorized for deposits and/or withdrawals made by customers.
-
-By default, this protection is disabled and can be activated upon request to our team.
-
-Once activated, customers will only be able to make deposits and/or withdrawals to bank accounts that have been previously registered. The management of these accounts can be done in two ways, which are detailed below.
-
-According to BACEN regulations, there is a limit of up to 3 accounts per customer.
-
-## QR Code Generation[](#qr-code-generation "Direct link to QR Code Generation")
-
-One of the ways to manage bank accounts is through the QR Code generation endpoint. In this process, all permitted accounts must be provided in each request.
-
-Example:
-
-URI:
-
-```
-POST /api/transaction/generate_qr_code_pix
-```
-
-Body:
-
-```
-{ "value": 10, "description": "Cobrança de deposito", "client_name": "Johnny", "client_email": "client@email.com", "client_document": "00000000000", "merchant_id": "271e4016-47de-45e0-9340-6f2560ce3a90", "expiration_date": "2024-01-25T18:25:43.000Z", "client_bank_accounts": [ { "bank_ispb": "11111111", "account_number": "111111", "account_branch": "1111" }, { "bank_ispb": "22222222", "account_number": "222222", "account_branch": "2222" } ]}
-```
-
-In the example above, the customer with document number 00000000000 will be authorized to make deposits and/or withdrawals to accounts 111111 and 222222. If the deposit is made through an account other than the registered ones, the transaction will be reversed. And if a different account is provided in the withdrawal request, the transaction will not be processed.
-
-The list of accounts sent will always replace the previous one. For example, if the next QR Code generated for this customer only includes account 111111, that will be the only account authorized for withdrawals, while account 222222 will be removed.
-
-## Customer Bank Account Management Endpoints[](#customer-bank-account-management-endpoints "Direct link to Customer Bank Account Management Endpoints")
-
-Customer bank account management can be done through different endpoints provided by the API. The system will always consider the last account submission, whether through the QR Code generation endpoint or the endpoints listed below.
-
-Here are the main operations:
-
-### List Bank Accounts of a Customer[](#list-bank-accounts-of-a-customer "Direct link to List Bank Accounts of a Customer")
-
-Returns all bank accounts registered for the customer.
-
-```
-GET /api/clients/{document}/bank-accounts
-```
-
-> **document** (required): Customer's document (CPF).
-
-### Define Bank Accounts[](#define-bank-accounts "Direct link to Define Bank Accounts")
-
-Adds new bank accounts to the customer. The provided accounts will replace the previous ones. This endpoint behaves the same as the one used for QR Code generation.
-
-```
-PUT /api/clients/{document}/bank-accounts
-```
-
-> **document** (required): Customer's document (CPF).
-
-### Register Bank Accounts[](#register-bank-accounts "Direct link to Register Bank Accounts")
-
-This endpoint allows registering one bank account at a time for the customer.
-
-```
-POST /api/clients/{document}/bank-accounts
-```
-
-> **document** (required): Customer's document (CPF).
-
-### Delete Bank Account[](#delete-bank-account "Direct link to Delete Bank Account")
-
-Removes a specific bank account associated with the customer.
-
-```
-DELETE /api/clients/{document}/bank-accounts/{bankAccountId}
-```
-
-> **document** (required): Customer's document (CPF).
-
-> **bankAccountId**: ID of the bank account to be removed.
-
-[
-
-Previous
-
-Errors
-
-](/gateway/api-overview/errors)[
-
-Next
-
-API Responses
-
-](/gateway/api-overview/api-responses)
-
-- [Customer Bank Account Registration](#customer-bank-account-registration)
-- [QR Code Generation](#qr-code-generation)
-- [Customer Bank Account Management Endpoints](#customer-bank-account-management-endpoints)
- - [List Bank Accounts of a Customer](#list-bank-accounts-of-a-customer)
- - [Define Bank Accounts](#define-bank-accounts)
- - [Register Bank Accounts](#register-bank-accounts)
- - [Delete Bank Account](#delete-bank-account)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/gateway/api-overview/webhooks",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Webhooks | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/gateway/api-overview/introduction)
-
- - [Introduction](/gateway/api-overview/introduction)
- - [Authentication](/gateway/api-overview/authentication)
- - [Protocol](/gateway/api-overview/protocol)
- - [Serialization](/gateway/api-overview/serialization)
- - [Errors](/gateway/api-overview/errors)
- - [How to use](/gateway/api-overview/how-to-use)
- - [API Responses](/gateway/api-overview/api-responses)
- - [Duplication Prevention](/gateway/api-overview/duplication-prevention)
- - [Changelog](/gateway/api-overview/changelog)
- - [Webhooks](/gateway/api-overview/webhooks)
-- [Endpoints](/gateway/endpoints/zrobank)
-
-
-- [](/)
-- API Overview
-- Webhooks
-
-On this page
-
-# Webhooks
-
-Webhooks enable real-time communication by automatically sending HTTP requests when events occur. Unlike APIs that require polling, webhooks push data to a specified URL, improving efficiency. Common uses include payment processing, notifications, and automation.
-
-The ZroBank API supports webhooks for various events, such as **payment status updates**, **withdraws**, **refunds** and **KYC** (Know Your Customer).
-
-## Webhooks URLs[](#webhooks-urls "Direct link to Webhooks URLs")
-
-All webhook URLs must be **HTTPS** and publicly accessible. The ZroBank API sends a `POST` request to the URL with a JSON payload (example below). These URLs must be provided to ZroBank Integration Team to enable the webhooks.
-
-The URLs we need:
-
-- **Payment Status Update**: URL to receive payment status updates.
-- **Withdraw**: URL to receive withdraw events.
-- **Refund**: URL to receive refund events.
-- **Returned Withdraw**: URL to receive returned withdraw events.
-- **KYC**: URL to receive KYC events.
-
-All URLs can be the same or different, depending on your requirements.
-
-## Webhook Security[](#webhook-security "Direct link to Webhook Security")
-
-By default, all webhooks are sent without any authentication. If you need to secure your webhooks, you can use the
-
-### OAuth2 Client Credentials Flow[](#oauth2-client-credentials-flow "Direct link to OAuth2 Client Credentials Flow")
-
-If all the URLs provided are an authenticated URL, we support the **OAuth2 Client Credentials** flow for authentication.
-
-- You need to provide the `client_id`, `client_secret` and `token endpoint` (commonly `/oauth/token`) to the ZroBank Integration Team.
-- We will call the token endpoint to get the access token.
-- All the next webhooks will include the access token in the `Authorization` header.
-
-You can read more about the OAuth2 Client Credentials flow [here](https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/).
-
-## Webhook Payloads[](#webhook-payloads "Direct link to Webhook Payloads")
-
-This section provides examples of the latest webhook payload versions. If you are using an outdated version, we recommend updating or contacting our [Support Team](/overview/support) for assistance.
-
-### Transactional Webhooks[](#transactional-webhooks "Direct link to Transactional Webhooks")
-
-Transactional Webhooks notify merchants of payment-related events, including payments, withdrawals, and refunds. Below, you will find different webhook versions and their respective payload structures, along with a detailed explanation of each field.
-
-- V7 (Transactions)
-- V6/V5/V4 (Transactions)
-- V3 (Transactions)
-- V7 (Withdraw)
-- V6/V5/V4 (Withdraw)
-- V6/V5 (Refund)
-- V4 (Refund)
-
-```
-{ "status": "paid", "webhook_type": "transaction", "transaction_uuid": "e2e30fe2-f7cf-4310-808e-faa60d70e9ee", "description": "Payment Description", "value": "1.16", "payment_date": "2025-02-12T19:29:22.000000", "end_to_end_id": "E26264220202502121929xKDMdFWi5Q5", "merchant_id": "c50539dc-94de-495b-958a-324edf76b348", "client": { "name": "José da Silva", "cpf_cnpj": "12345678900" }, "payer": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "***004714**", "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220", "paid_by_client": false, "kyc": { "ofLegalAge": true, "birthdate": "1955-01-16T00:00:00", "suspectedDeath": false, "pep": null, "age": 70 } }, "receiver": null, "refund": null, "bank_account_data": { "bank_name": "ZRO PAGAMENTOS S.A.", "bank_ispb": "26264220", "account_number": "5684", "account_digit": "1", "account_branch": "0001", "account_type": "CACC" }}
-```
-
-```
-{ "status": "paid", "webhook_type": "transaction", "transaction_uuid": "e2e30fe2-f7cf-4310-808e-faa60d70e9ee", "description": "Payment Description", "value": "1.16", "payment_date": "2025-02-12T19:29:22.000000", "end_to_end_id": "E26264220202502121929xKDMdFWi5Q5", "merchant_id": "c50539dc-94de-495b-958a-324edf76b348", "client": { "name": "José da Silva", "cpf_cnpj": "12345678900" }, "payer": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "***004714**", "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220", "paid_by_client": false, "kyc": { "ofLegalAge": true, "birthdate": "1955-01-16T00:00:00", "suspectedDeath": false, "pep": null, "age": 70 } }, "receiver": null, "refund": null, "bank_account_data": { "bank_name": "ZRO PAGAMENTOS S.A.", "bank_ispb": "26264220", "account_number": "56841", "account_branch": "0001", "account_type": "CACC" }}
-```
-
-```
-{ "status": "paid", "webhook_type": "transaction", "transaction_uuid": "e2e30fe2-f7cf-4310-808e-faa60d70e9ee", "description": "Payment Description", "value": "1.16", "payment_date": "2025-02-12T19:29:22.000000", "end_to_end_id": "E26264220202502121929xKDMdFWi5Q5", "merchant_id": "c50539dc-94de-495b-958a-324edf76b348", "client": { "name": "José da Silva", "cpf_cnpj": "12345678900" }, "payer": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "***004714**", "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220", "paid_by_client": false, "kyc": { "ofLegalAge": true, "birthdate": "1955-01-16T00:00:00", "suspectedDeath": false, "pep": null, "age": 70 } }, "receiver": null, "refund": null}
-```
-
-```
-{ "status": "paid", "webhook_type": "withdraw", "transaction_uuid": "01dea582-a6ad-59f8-8ec4-7dfedf23fd50", "description": "Payment Description", "value": "1.01", "payment_date": "2025-02-12T19:29:22.000000", "end_to_end_id": "E26264220202502121929xKDMdFWi5Q5", "merchant_id": "2b541929-6ea2-4259-913e-45edd05178d0", "client": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "12345678900" }, "payer": null, "receiver": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "12345678900", "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220" }, "refund": null, "bank_account_data": { "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220", "account_number": "8720077", "account_digit": "7", "account_branch": "0001", "account_type": "CACC" }}
-```
-
-```
-{ "status": "paid", "webhook_type": "withdraw", "transaction_uuid": "01dea582-a6ad-59f8-8ec4-7dfedf23fd50", "description": "Payment Description", "value": "1.01", "payment_date": "2025-02-12T19:29:22.000000", "end_to_end_id": "E26264220202502121929xKDMdFWi5Q5", "merchant_id": "2b541929-6ea2-4259-913e-45edd05178d0", "client": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "12345678900" }, "payer": null, "receiver": { "name": "Maria Ferreira Da Silva", "cpf_cnpj": "12345678900", "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220" }, "refund": null, "bank_account_data": { "bank_name": "Zro Pagamento S.A", "bank_ispb": "26264220", "account_number": "8720077", "account_branch": "0001", "account_type": "CACC" }}
-```
-
-```
-{ "status": "paid", "webhook_type": "refund", "transaction_uuid": "1f1a1031-2cb7-474e-ad13-deb5a8f92d27", "description": "Refund Description", "value": "1.00", "payment_date": "2025-02-12T21:30:51.000000", "end_to_end_id": "D26264220202502122130unPayQe0TZA", "merchant_id": "f157244c-0d1f-4fd8-9329-e3222a981e76", "client": { "name": "José da Silva", "cpf_cnpj": "12345678900" }, "payer": null, "receiver": { "name": "José da Silva", "cpf_cnpj": "12345678900", "bank_name": "FACTA S.A. CFI", "bank_ispb": "15581638" }, "refund": { "transaction_parent_uuid": "dbbb6c6f-a7d5-4162-9569-4aa0de58c6e2", "transaction_parent_merchant_id": "07d464eb-df1c-45a0-9e43-b275cec7b1da", "error_code": "INVALID_PAYER_DOCUMENT" }, "bank_account_data": { "bank_name": "FACTA S.A. CFI", "bank_ispb": "15581638", "account_number": "152", "account_branch": "5856", "account_type": "" }}
-```
-
-```
-{ "status": "paid", "webhook_type": "refund", "transaction_uuid": "1f1a1031-2cb7-474e-ad13-deb5a8f92d27", "description": "Refund Description", "value": "1.00", "payment_date": "2025-02-12T21:30:51.000000", "end_to_end_id": "D26264220202502122130unPayQe0TZA", "merchant_id": "f157244c-0d1f-4fd8-9329-e3222a981e76", "client": { "name": "José da Silva", "cpf_cnpj": "12345678900" }, "payer": null, "receiver": { "name": "José da Silva", "cpf_cnpj": "12345678900", "bank_name": "FACTA S.A. CFI", "bank_ispb": "15581638" }, "refund": { "transaction_parent_uuid": "dbbb6c6f-a7d5-4162-9569-4aa0de58c6e2" }, "bank_account_data": { "bank_name": "FACTA S.A. CFI", "bank_ispb": "15581638", "account_number": "152", "account_branch": "5856", "account_type": "" }}
-```
-
-#### Fields Description[](#fields-description "Direct link to Fields Description")
-
-Field
-
-Possible Values/Format
-
-Description
-
-`status`
-
-`"paid"`, `"failed"`
-
-The status of the transaction.
-
-`webhook_type`
-
-`"transaction"`, `"withdraw"`, `"refund"`
-
-The type of the webhook event.
-
-`transaction_uuid`
-
-String (UUID format)
-
-A unique identifier for the transaction.
-
-`description`
-
-String
-
-A description of the payment.
-
-`value`
-
-Numeric String (e.g., `"10.75"`)
-
-The transaction amount in the respective currency.
-
-`payment_date`
-
-String (ISO 8601 format, e.g., `"2023-01-01T12:11:39.090"`)
-
-The date and time when the payment was processed.
-
-`end_to_end_id`
-
-String (alphanumeric)
-
-A unique identifier for tracking the transaction.
-
-`merchant_id`
-
-String
-
-A unique identifier passed by merchant to identify the transaction.
-
-`client`
-
-Object
-
-The client who generated the QR code, requested withdraw or received refund.
-
-`client.name`
-
-String
-
-The name of the client associated with the transaction.
-
-`client.cpf_cnpj`
-
-Numeric String (CPF: 11 digits, CNPJ: 14 digits)
-
-The unmasked CPF or CNPJ of the client.
-
-`payer`
-
-(nullable) Object
-
-The payer's data. Null when the `webhook_type` is **not** `transaction`.
-
-`payer.name`
-
-String
-
-The name of the payer.
-
-`payer.cpf_cnpj`
-
-String (CPF: 11 digits, CNPJ: 14 digits)
-
-The payer’s CPF or CNPJ. May be masked.
-
-`payer.bank_name`
-
-String
-
-The name of the payer’s bank.
-
-`payer.bank_ispb`
-
-Numeric String (8-digit ISPB code)
-
-The ISPB (bank identifier) of the payer’s bank.
-
-`payer.paid_by_client`
-
-Boolean: `true`, `false`
-
-Indicates if the payer is the client who generated the QR code.
-
-`payer.kyc`
-
-Object or Empty Object
-
-KYC (Know Your Customer) data for the payer. May be an empty object.
-
-`payer.kyc.ofLegalAge`
-
-(nullable) Boolean
-
-Indicates if the client is of legal age.
-
-`payer.kyc.birthdate`
-
-(nullable) String (ISO format)
-
-The client’s birth date.
-
-`payer.kyc.age`
-
-(nullable) Integer
-
-The client’s age.
-
-`payer.kyc.pep`
-
-(nullable) Boolean
-
-Indicates if the client is a PEP (Politically Exposed Person).
-
-`payer.kyc.suspectedDeath`
-
-(nullable) Boolean
-
-Indicates if the client is suspected to have passed away.
-
-`receiver`
-
-(nullable) Object
-
-The receiver's data. Null when the `webhook_type` is not `withdraw` or `refund`.
-
-`receiver.name`
-
-String
-
-The name of the receiver.
-
-`receiver.cpf_cnpj`
-
-Numeric String (CPF: 11 digits, CNPJ: 14 digits)
-
-The unmasked CPF or CNPJ of the receiver.
-
-`receiver.bank_name`
-
-String
-
-The name of the receiver’s bank.
-
-`receiver.bank_ispb`
-
-Numeric String (8-digit ISPB code)
-
-The ISPB (bank identifier) of the receiver’s bank.
-
-`refund`
-
-(nullable) Object
-
-Refund data. Null when the `webhook_type` is **not** `refund`.
-
-`refund.transaction_parent_uuid`
-
-String (UUID format)
-
-The UUID of the original transaction if this is a refund.
-
-`refund.transaction_parent_merchant_id`
-
-String (UUID format)
-
-The merchant ID of the original transaction if this is a refund.
-
-`refund.error_code`
-
-ISPB\_NOT\_IN\_PERMISSION\_LIST", "INVALID\_PAID\_VALUE", "INVALID\_PAYER\_DOCUMENT", "KYC\_RESTRICTION", "INVALID\_PAYER\_BANK\_ACCOUNT", "INVALID\_DEPOSIT\_FROM\_JURIDIC\_PERSON"
-
-Error code when an automatic (due to company policies validations) refund happens.
-
-`bank_account_data`
-
-Object
-
-Payer's bank account data.
-
-`bank_account_data.bank_name`
-
-String
-
-The name of the bank where the QR code was paid.
-
-`bank_account_data.bank_ispb`
-
-Numeric String (8-digit ISPB code)
-
-The ISPB code of the bank.
-
-`bank_account_data.account_number`
-
-Numeric String (may be empty)
-
-The account number from which the payment originated.
-
-`bank_account_data.account_digit`
-
-Numeric String (may be empty)
-
-The account number digit from which the payment originated.
-
-`bank_account_data.account_branch`
-
-Numeric String (may be empty)
-
-The branch number of the payer’s bank account.
-
-`bank_account_data.account_type`
-
-`"CACC"`, `"SVGS"`, `"SLRY"`, `"CASH"`, `"TRAN"`, `"TAXE"`, `"OTHR"` (may be empty)
-
-The type of account.
-
-### KYC Webhook[](#kyc-webhook "Direct link to KYC Webhook")
-
-The KYC (Know Your Customer) Webhook provides real-time verification data for payers involved in transactions (when enabled). Below is the JSON payload structure returned by the webhook.
-
-- V1
-
-```
-{ "name": "José da Silva", "document": "12345678900", "age": 54, "ofLegalAge": true, "suspectedDeath": false, "pep": null, "merchantId": "761f802a-1635-4b21-acd0-858277cc5c45", "transactionUuid": "215e8f33-183f-4fd7-8ec1-346ca9999184"}
-```
-
-#### Fields Description[](#fields-description-1 "Direct link to Fields Description")
-
-Field
-
-Possible Values/Format
-
-Description
-
-`name`
-
-String
-
-Full name of the individual.
-
-`document`
-
-String Numbers Only
-
-Identification document number (e.g., CPF in Brazil).
-
-`age`
-
-Integer
-
-The age of the individual.
-
-`ofLegalAge`
-
-Boolean
-
-Indicates whether the individual is of legal age (18 or older).
-
-`suspectedDeath`
-
-Boolean
-
-Indicates if there is suspicion of the individual’s death.
-
-`pep`
-
-(nullable) Boolean
-
-Politically Exposed Person status; `null` if not applicable.
-
-`merchantId`
-
-String (UUID format)
-
-Unique identifier for the merchant.
-
-`transactionUuid`
-
-String (UUID format)
-
-Unique identifier for the transaction.
-
-## Support[](#support "Direct link to Support")
-
-It’s always a pleasure to help you! If you need assistance with the integration or have any questions, please feel free to use our documentation and do not hesitate to [contact us](/overview/support).
-
-[
-
-Previous
-
-Changelog
-
-](/gateway/api-overview/changelog)[
-
-Next
-
-Introduction
-
-](/gateway/endpoints/zrobank)
-
-- [Webhooks URLs](#webhooks-urls)
-- [Webhook Security](#webhook-security)
- - [OAuth2 Client Credentials Flow](#oauth2-client-credentials-flow)
-- [Webhook Payloads](#webhook-payloads)
- - [Transactional Webhooks](#transactional-webhooks)
- - [KYC Webhook](#kyc-webhook)
-- [Support](#support)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/api-overview/idempotence",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Idempotence | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
- - [Introduction](/baas/api-overview/introduction)
- - [Authentication](/baas/api-overview/authentication)
- - [Protocol](/baas/api-overview/protocol)
- - [Idempotence](/baas/api-overview/idempotence)
- - [Rate Limiting](/baas/api-overview/rate-limiting)
- - [Request ID (Nonce)](/baas/api-overview/request-id)
- - [Serialization](/baas/api-overview/serialization)
- - [Replay Protection](/baas/api-overview/replay)
- - [Pagination](/baas/api-overview/pagination)
- - [API Responses](/baas/api-overview/api-responses)
- - [Changelog](/baas/api-overview/changelog)
- - [Webhooks](/baas/api-overview/webhooks)
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
-
-- [](/)
-- API Overview
-- Idempotence
-
-# Idempotence
-
-Idempotence is a fundamental concept in our API, as it ensures that the same request can be made multiple times without causing unwanted side effects, maintaining data consistency.
-
-When making a request to our API, it is automatically forwarded to Kafka, a distributed messaging system that allows us to work with real-time data and ensure its integrity. This way, we can ensure that each request is treated independently and with total security, without causing side effects or inconsistencies in the data.
-
-[
-
-Previous
-
-Protocol
-
-](/baas/api-overview/protocol)[
-
-Next
-
-Rate Limiting
-
-](/baas/api-overview/rate-limiting)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 49.3s)
-
-_Thinking:_
-
-**Considering payment options**
-
-I need to think about whether we want card acceptance or a consumer-facing merchant collection. That might require separate gateway or merchant onboarding with Dock acquiring. If our design partners already have their payment processors and we're just reconciling trusted payment data, we might not actually need the Z.ro Gateway at launch. If we go for collecting via Pix, maybe PaaS/BaaS would be sufficient for that. Card acceptance via Z.ro could require a separate gateway for merchant onboarding. Perhaps we can defer some of these decisions for now.
-
-_Thinking:_
-
-**Considering endpoint details**
-
-I need to answer accurately, and while I have enough information, I might need specific endpoint details. I could fetch relevant documentation for exact names or mention endpoint paths from onboarding. I already have some path names, but understanding PaaS/BaaS differences could help. It’s crucial to address `x-product-uuid` and `x-product-target-user-uuid`, as they indicate one platform product with multiple end users. Mentioning how product/user delegation works and confirming with Z.ro would be important too.
-
-_Thinking:_
-
-**Reviewing documentation needs**
-
-I’m considering whether an explore agent is necessary, but I might need real page content for international payment gateway docs. The user wants me to go over documentation and identify exactly what we need. I can reference public docs, but I should highlight their limitations as they don’t include critical pricing and regulatory terms, which need to be confirmed with Z.ro. It might help to compile this into a due diligence questionnaire and clarify if the user prefers a narrow v1 or full stack approach. Assuming a Brazil-first approach, I could mention that in my response.
-
-_Thinking:_
-
-**Considering documentation alignment**
-
-I could reference `docs/core-idea.md` and potentially use code or file references, though it might not be necessary. I might want to mention, "Based on our current Brazil-first v1: payment-linked commission calculation + Pix cash-out." While it probably isn't essential to cite specific file lines, mentioning our repo thesis could be helpful. I should also think about computing the exact required flows and steps. This aligns with our startup thesis around employer workflows, payment-linked commissions, and instant access to earned commissions.
-
-_Thinking:_
-
-**Evaluating onboarding solutions**
-
-I'm considering the onboarding process. It looks like BaaS is the best option for user and company onboarding, especially since we need wallet/account management and employee balances. PaaS might only be necessary if we don't onboard end users. I should assess the exact needs because using just BaaS might work since it provides access to Pix services, including payments and wallets. The documentation shows options for both, so I need to be careful about assuming one will suffice over the other.
-
-_Thinking:_
-
-**Assessing financial architecture**
-
-I'm exploring how PaaS could work, but since we need user accounts and onboarding, BaaS seems essential. BaaS is likely our core contract, while PaaS may be redundant for our initial version unless they offer packaged Pix services with better pricing. We also need an internal ledger that tracks various states and manages the commission engine, reserve logic, dashboards, and audit trails. I can't rely on Z.ro wallet balances for this, as they only reflect banking movements, so I must ensure a clear mapping between sales, employer rules, and ledger entries.
-
-_Thinking:_
-
-**Deciding on cash-out flow**
-
-For the cash-out flow, once the commission is available in our ledger, we can either execute a Pix payment from the employer or platform wallet directly to the employee's external account, or transfer funds to the employee's Z.ro wallet for them to withdraw or use later. I really need to decide which model is better. Currently, my thinking leans towards partner-held custody with a later stored balance or card, while starting V1 with Pix for instant cash-out and a stored balance afterward.
-
-_Thinking:_
-
-**Fetching payment documentation**
-
-I’m considering whether we should gather specific documentation for the Pix payment endpoint and P2P transfers. That could help clarify things. I’m also thinking about fetching docs related to creating user accounts and product targets, although we already have onboarding covered. To recommend a minimal model, I need to confirm if payouts can go to an external Pix key. Let’s focus on the Pix payment endpoint, including wallet headers and payment body details, particularly the beneficiary Pix key and idempotency headers.
-
-I’m validating the payout-side mechanics before I wrap this up, because that determines whether we need full employee bank accounts on day one or can start with simpler Pix cash-out.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Create Decoded Pix Key ID | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Create Decoded Pix Key ID](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
- - [Create Decoded QR Code](/baas/endpoints/v-2-create-decoded-qr-code-rest-controller-execute-v-2)
- - [Create Decoded Pix Account ID](/baas/endpoints/v-1-create-decoded-pix-account-rest-controller-execute-v-1)
- - [Create Pix Payment by Bank Account](/baas/endpoints/v-2-create-by-account-payment-rest-controller-execute-v-2)
- - [Decode and Create Pix Payment by Bank Account](/baas/endpoints/v-1-decode-and-create-by-account-payment-rest-controller-execute-v-1)
- - [Withdraw Payment with Static QR Code](/baas/endpoints/v-1-withdrawal-by-qr-code-static-payment-rest-controller-execute-v-1)
- - [Withdraw Payment with Dynamic QR Code](/baas/endpoints/v-1-withdrawal-by-qr-code-dynamic-payment-rest-controller-execute-v-1)
- - [Create Due Date Payment with Dynamic QR Code](/baas/endpoints/v-1-duedate-by-qr-code-dynamic-payment-rest-controller-execute-v-1)
- - [Create Change Payment with Dynamic QR Code](/baas/endpoints/v-1-change-by-qr-code-dynamic-payment-rest-controller-execute-v-1)
- - [Create Payment with Dynamic QR Code](/baas/endpoints/v-1-create-by-qr-code-dynamic-payment-rest-controller-execute-v-1)
- - [Create Payment with Static QR Code](/baas/endpoints/v-1-create-by-qr-code-static-payment-rest-controller-execute-v-1)
- - [Create Pix Payment by Pix Key](/baas/endpoints/v-1-create-by-pix-key-payment-rest-controller-execute-v-1)
- - [Decode and Create Pix Payment by Pix Key](/baas/endpoints/v-1-decode-and-create-by-pix-key-payment-rest-controller-execute-v-1)
- - [Cancel Payment by Operation ID](/baas/endpoints/v-1-cancel-payment-by-operation-id-rest-controller-execute-v-1)
- - [List Pix Payments](/baas/endpoints/v-1-get-all-payment-rest-controller-execute-v-1)
- - [Get Pix Payment by ID](/baas/endpoints/v-1-get-payment-by-id-rest-controller-execute-v-1)
- - [Create Pix Trusted Contact](/baas/endpoints/v-1-create-pix-trusted-contact-rest-controller-execute-v-1)
- - [List Pix Trusted Contact](/baas/endpoints/v-1-get-all-pix-trusted-contact-by-wallet-rest-controller-execute-v-1)
- - [Get Pix Trusted Contact by ID](/baas/endpoints/v-1-get-pix-trusted-contact-by-id-and-wallet-rest-controller-execute-v-1)
- - [Delete pix trusted contact](/baas/endpoints/v-1-delete-pix-trusted-contact-rest-controller-execute-v-1)
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Pix | Payments
-- Create Decoded Pix Key ID
-
-# Create Decoded Pix Key ID
-
-GET
-
-## /v1/pix/payments/decode/by-key
-
-Generate a new Decoded Pix Key ID to facilitate pix payments by pix key. Provide the pix key's information in the request body and execute to obtain its ID (decoded\_pix\_key\_id), which is required for creating pix payments using a pix key.
-
-## Request[](#request "Direct link to Request")
-
-### Query Parameters
-
-**key** stringrequired
-
-Pix key.
-
-**type** stringrequired
-
-**Possible values:** \[`CNPJ`, `CPF`, `PHONE`, `EMAIL`, `EVP`\]
-
-Pix Key state:
-
-- CPF: Key type CPF.
-- EVP: Key type EVP.
-- EMAIL: Key type EMAIL.
-- PHONE: Key type PHONE.
-- CNPJ: Key type CNPJ.
-
-### Header Parameters
-
-**x-transaction-uuid** stringrequired
-
-The transaction ID is a UUID (v4) used to uniquely identify the object that will be created. All objects must have an identifier.
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** stringrequired
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 200
-- 400
-- 401
-- 422
-
-Pix key decoded successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-Unique decoded pix key UUID.
-
-**type** stringrequired
-
-**Possible values:** \[`CNPJ`, `CPF`, `PHONE`, `EMAIL`, `EVP`\]
-
-Pix Key state:
-
-- CPF: Key type CPF.
-- EVP: Key type EVP.
-- EMAIL: Key type EMAIL.
-- PHONE: Key type PHONE.
-- CNPJ: Key type CNPJ.
-
-**person\_type** stringrequired
-
-**Possible values:** \[`NATURAL_PERSON`, `LEGAL_PERSON`\]
-
-**key** stringrequired
-
-Pix key.
-
-**document** stringrequired
-
-Owner document number.
-
-**name** stringrequired
-
-Owner name.
-
-**trade\_name** string
-
-Company's trade name.
-
-**end\_to\_end\_id** stringrequired
-
-**ispb** stringrequired
-
-Bank ISPB.
-
-**bank\_name** stringrequired
-
-Bank name.
-
-```
-{ "id": "d5e0bec8-8695-4557-b0dd-021788cd83ef", "type": "EMAIL", "person_type": "LEGAL_PERSON", "key": "string", "document": "string", "name": "string", "trade_name": "string", "end_to_end_id": "string", "ispb": "string", "bank_name": "string"}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Dismiss Pix Key
-
-](/baas/endpoints/v-2-dismiss-by-id-pix-key-rest-controller-execute-v-2)[
-
-Next
-
-Create Decoded QR Code
-
-](/baas/endpoints/v-2-create-decoded-qr-code-rest-controller-execute-v-2)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Create P2P Transfer | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Create P2P Transfer](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
- - [Get P2P Transfer by ID](/baas/endpoints/v-1-get-p-2-p-transfer-by-id-rest-controller-execute-v-1)
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Operations | P2P Transfers
-- Create P2P Transfer
-
-# Create P2P Transfer
-
-POST
-
-## /v1/operations/p2p-transfers
-
-Initiate a peer-to-peer (P2P) fund transfer within your organization, allowing transfers between Master Account and Sub-account wallets. Specify the UUID of the wallet you are transferring funds from in the "x-wallet-uuid" header. If the "x-wallet-uuid" param is omitted, your default wallet will be used. Provide the destination wallet and transaction details in the request body and execute to complete the transaction.
-
-## Request[](#request "Direct link to Request")
-
-### Header Parameters
-
-**x-include-replay-protection-schema** string
-
-The replay-protection-schema allows the user to choose between 3 options:
-
-- If there's no value: The default protection checks that the values in this request are equal: **{ method, params, path, query, body, userId }.** This means that if a request repeats the same values, it will be blocked.
-- 'nonce': The nonce and **{ method, params, path, query, body, userId }** value are checked. When the protection schema is this, requests will be OK if this nonce value is different in each request.
-- 'x-transaction-uuid': The transactionId and **{ method, params, path, query, body, userId }** value are checked. Requests will be OK if this x-transaction-uuid value is different in each request.
-- 'x-transaction-uuid&nonce' or 'nonce&x-transaction-uuid': The nonce, transactionId value and **{ method, params, path, query, body, userId }** are checked, i.e. if requests are repeated the same value in both fields, they will be blocked. But if any field has a different value, the request is OK.
-
-**x-transaction-uuid** stringrequired
-
-The transaction ID is a UUID (v4) used to uniquely identify the object that will be created. All objects must have an identifier.
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-- application/json
-
-### Body
-
-**required**
-
-**destination\_wallet\_id** string
-
-Destination wallet UUID.
-
-**amount\_currency** stringrequired
-
-Transfer currency amount symbol.
-
-**amount** numberrequired
-
-Transfer amount in cents.
-
-**fee** numberrequired
-
-Transfer fee in cents.
-
-**description** string
-
-Transfer description.
-
-**merchant\_id** string
-
-User defined payment merchant ID.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 201
-- 400
-- 401
-- 422
-
-Transfer response.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**id** stringrequired
-
-Transfer UUID.
-
-**operation\_id** stringrequired
-
-Transfer Operation UUID.
-
-**amount\_currency** stringrequired
-
-Transfer currency amount.
-
-**amount** numberrequired
-
-Transfer amount in cents.
-
-**fee** numberrequired
-
-Transfer fee in cents.
-
-**description** stringnullable
-
-Transfer description.
-
-**created\_at** date-timerequired
-
-Transfer created at.
-
-```
-{ "id": "f6e2e084-29b9-4935-a059-5473b13033aa", "operation_id": "f6e2e084-29b9-4935-a059-5473b13033aa", "amount_currency": "BRL", "amount": 1299, "fee": 10, "description": "string", "created_at": "2026-03-26T14:02:58.521Z"}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Create a New Permission Type
-
-](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)[
-
-Next
-
-Get P2P Transfer by ID
-
-](/baas/endpoints/v-1-get-p-2-p-transfer-by-id-rest-controller-execute-v-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- List Wallets | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [List Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
- - [Create Wallet](/baas/endpoints/v-1-create-wallet-rest-controller-execute-v-1)
- - [Get Wallet by ID](/baas/endpoints/v-1-get-wallet-by-id-rest-controller-execute-v-1)
- - [Update Wallet Name](/baas/endpoints/v-1-update-wallet-rest-controller-execute-v-1)
- - [Delete Wallet](/baas/endpoints/v-1-delete-wallet-rest-controller-execute-v-1)
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Operations | Wallets
-- List Wallets
-
-# List Wallets
-
-GET
-
-## /v1/operations/wallets
-
-Retrieve a list of the user's wallets. You can include any of the filter parameters below to refine your search.
-
-## Request[](#request "Direct link to Request")
-
-### Query Parameters
-
-**owner** string
-
-**Possible values:** \[`USER`, `OTHER`, `ADMIN`\]
-
-User wallet owner type.
-
-### Header Parameters
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 200
-- 400
-- 401
-- 422
-
-The wallets returned successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-- Array \[
-
-
-**id** stringrequired
-
-Wallet id.
-
-**name** stringrequired
-
-Wallet name.
-
-**default** booleanrequired
-
-Wallet default flag.
-
-**state** stringrequired
-
-**Possible values:** \[`pending`, `active`, `deactivate`, `blocked`\]
-
-Wallet state.
-
-**permission\_types** string\[\]required
-
-Wallet permission type that defines what the user can do.
-
-**owner\_id** stringrequired
-
-Wallet owner id.
-
-**owner\_name** stringrequired
-
-Wallet owner name.
-
-**created\_at** date-timerequired
-
-Wallet created at.
-
-- \]
-
-
-```
-[ { "id": "f6e2e084-29b9-4935-a059-5473b13033aa", "name": "BTC", "default": false, "state": "active", "permission_types": [ "CLIENT" ], "owner_id": "f6e2e084-29b9-4935-a059-5473b13033aa", "owner_name": "James Bond", "created_at": "2026-03-26T14:02:59.116Z" }]
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-Create SPOT Quotation
-
-](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)[
-
-Next
-
-Create Wallet
-
-](/baas/endpoints/v-1-create-wallet-rest-controller-execute-v-1)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://coinwise-io.github.io/zrobank-doc-api/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- List Operations | Z.ro Bank
-
-[Skip to main content](#__docusaurus_skipToContent_fallback)
-
-[
-
-
-
-](/)[Overview](/overview/introduction)[Banking as a Service](/baas/api-overview/introduction)[Crypto as a Service](/caas/api-overview/introduction)[Gateway](/gateway/api-overview/introduction)[Pix as a Service](/paas/api-overview/introduction)
-
-[Payments Gateway](https://docs-international.zrobank.io)
-
-- [API Overview](/baas/api-overview/introduction)
-
-- [Guides](/baas/guides/legal-person-onboarding)
-
-- [Endpoints](/baas/endpoints/zro-global-baas-api)
-
- - [Introduction](/baas/endpoints/zro-global-baas-api)
- - [Authentication](/baas/endpoints/v-1-login-auth-rest-controller-execute-v-1)
-
- - [Pix | Keys](/baas/endpoints/v-1-get-all-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Payments](/baas/endpoints/v-1-create-decoded-pix-key-rest-controller-execute-v-1)
-
- - [Pix | Devolutions](/baas/endpoints/v-1-create-pix-devolution-rest-controller-execute-v-1)
-
- - [Pix | Deposits](/baas/endpoints/v-1-get-all-pix-deposit-rest-controller-execute-v-1)
-
- - [Otc | Conversions](/baas/endpoints/v-1-create-conversion-rest-controller-execute-v-1)
-
- - [Quotations | Conversions](/baas/endpoints/v-1-get-quotation-rest-controller-execute-v-1)
-
- - [Operations | Wallets](/baas/endpoints/v-1-get-all-wallet-rest-controller-execute-v-1)
-
- - [Permissions | Permission Types](/baas/endpoints/create-permission-type-rest-controller-execute-v-1)
-
- - [Operations | P2P Transfers](/baas/endpoints/v-1-create-p-2-p-transfer-rest-controller-execute-v-1)
-
- - [Operations | Wallet Accounts](/baas/endpoints/v-1-get-all-wallet-account-rest-controller-execute-v-1)
-
- - [Operations | Currency](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)
-
- - [Operations | Operation](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
-
- - [List Operations](/baas/endpoints/v-1-get-all-operations-rest-controller-execute-v-1)
- - [Get Operation by ID](/baas/endpoints/v-1-get-operation-by-id-rest-controller-execute-v-1)
- - [Get Receipt by Operation ID](/baas/endpoints/v-1-get-operation-receipt-by-id-rest-controller-execute-v-1)
- - [Request Receipt PDF Generation by Operation ID](/baas/endpoints/v-1-generate-operation-receipt-pdf-by-user-and-wallet-and-id-rest-controller-execute-v-1)
- - [Get Pending Balance](/baas/endpoints/get-pending-sum-by-wallet-account-rest-controller-execute-v-1)
- - [Banking](/baas/endpoints/v-1-get-all-banking-ted-received-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposits](/baas/endpoints/v-1-create-banking-billet-pix-deposit-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Template](/baas/endpoints/v-1-create-banking-billet-pix-deposit-template-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Payments](/baas/endpoints/v-1-get-banking-billet-payment-by-id-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-rest-controller-execute-v-1)
-
- - [Banking | Bank Billet | Pix Deposit Batch Item](/baas/endpoints/v-1-create-banking-billet-pix-deposit-batch-item-rest-controller-execute-v-1)
-
- - [Utils | User Withdraw Settings](/baas/endpoints/v-1-get-all-user-withdraw-setting-rest-controller-execute-v-1)
-
- - [Health](/baas/endpoints/health-controller-execute)
-
- - [Reports](/baas/endpoints/v-3-generate-pix-statement-export-rest-controller-execute-v-3)
-
- - [Storage](/baas/endpoints/v-1-get-all-files-rest-controller-execute-v-1)
-
- - [Users | User Account](/baas/endpoints/v-1-delete-user-account-rest-controller-execute-v-1)
-
- - [Users | User Bank Account](/baas/endpoints/v-1-get-user-bank-account-by-wallet-rest-controller-execute-v-1)
-
- - [Users | Legal Person](/baas/endpoints/v-1-get-all-legal-person-onboarding-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding](/baas/endpoints/v-1-create-onboarding-rest-controller-execute-v-1)
-
- - [Users | Legal Representative](/baas/endpoints/v-2-get-all-legal-representative-rest-controller-execute-v-2)
-
- - [Users | Company Document](/baas/endpoints/v-1-upload-company-document-rest-controller-execute-v-1)
-
- - [Users | Natural Person Onboarding | Occupation](/baas/endpoints/v-1-get-all-occupation-rest-controller-execute-v-1)
-
- - [Users | Shareholder](/baas/endpoints/v-1-create-shareholder-rest-controller-execute-v-1)
-
- - [Users | Merchant Onboarding](/baas/endpoints/v-1-create-merchant-onboarding-rest-controller-execute-v-1)
-
- - [Users | Company Registration](/baas/endpoints/v-1-create-company-registration-rest-controller-execute-v-1)
-
- - [Card](/baas/endpoints/v-1-create-virtual-card-rest-controller-execute-v-1)
-
- - [Card | Onboarding](/baas/endpoints/v-1-get-terms-of-use-rest-controller-execute-v-1)
-
- - [Pix | Scheduled Payments](/baas/endpoints/get-all-pix-scheduled-payment-rest-controller-execute-v-1)
-
- - [Pix | Automatic Receiver Limits](/baas/endpoints/create-pix-automatic-receiver-limit-rest-controller-execute-v-1)
-
- - [Open Finance | Participants](/baas/endpoints/v-1-get-all-open-finance-participants-rest-controller-execute-v-1)
-
- - [Open Finance | Payment Consents](/baas/endpoints/v-1-create-open-finance-payment-consent-by-pix-key-rest-controller-execute-v-1)
-
- - [Open Finance | Payments](/baas/endpoints/v-1-create-open-finance-payment-rest-controller-execute-v-1)
-
- - [Crossborder | Clients](/baas/endpoints/v-1-create-client-rest-controller-execute-v-1)
-
- - [Crossborder | Client Documents](/baas/endpoints/v-1-upload-client-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Accounts](/baas/endpoints/v-1-create-client-account-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallets](/baas/endpoints/v-1-create-client-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Client Wallet Documents](/baas/endpoints/v-1-upload-client-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Client Account Documents](/baas/endpoints/v-1-upload-client-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Quotes](/baas/endpoints/v-1-upload-quote-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Rates](/baas/endpoints/v-1-get-rate-rest-controller-execute-v-1)
-
- - [Crossborder | Deposits](/baas/endpoints/v-1-get-deposit-info-by-quote-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparties](/baas/endpoints/v-1-create-counterparty-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Documents](/baas/endpoints/v-1-upload-counterparty-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Accounts](/baas/endpoints/v-1-create-counterparty-account-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallets](/baas/endpoints/v-1-create-counterparty-wallet-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Wallet Documents](/baas/endpoints/v-1-upload-counterparty-wallet-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Counterparty Account Documents](/baas/endpoints/v-1-upload-counterparty-account-document-file-rest-controller-execute-v-1)
-
- - [Crossborder | Stream Quotations](/baas/endpoints/v-1-get-stream-quotation-by-filter-rest-controller-execute-v-1)
-
- - [Schemas](/baas/endpoints/schemas/v-1-authenticaterestrequest)
-
-
-- [](/)
-- Endpoints
-- Operations | Operation
-- List Operations
-
-# List Operations
-
-GET
-
-## /v1/operations
-
-Retrieve a list of the user's operations.
-
-## Request[](#request "Direct link to Request")
-
-### Query Parameters
-
-**page** number
-
-**Default value:** `1`
-
-Page number.
-
-**size** number
-
-**Possible values:** `<= 100`
-
-**Default value:** `20`
-
-Page size. Max size is 100.
-
-**sort** string
-
-**Possible values:** \[`created_at`\]
-
-Page sort attribute.
-
-**order** string
-
-**Possible values:** \[`asc`, `desc`\]
-
-**Default value:** `asc`
-
-Page order.
-
-**currency\_symbol** string
-
-Operation currency symbol.
-
-**transaction\_tag** string
-
-Operation Transaction tag.
-
-**created\_at\_start** date-time
-
-Operation Created at start.
-
-**created\_at\_end** date-time
-
-Operation Created at end.
-
-### Header Parameters
-
-**x-wallet-uuid** string
-
-Sender Wallet UUID (if empty, your default Wallet UUID will be settled)
-
-**nonce** stringrequired
-
-The nonce ID is a UUID (v4) used to uniquely identify the request. All requests must have an identifier.
-
-**x-lang** string
-
-**Possible values:** \[`pt-BR`, `en-US`\]
-
-Indicates the preferred language. Defaults to Brazilian Portuguese if unspecified.
-
-**x-product-uuid** string
-
-UUID (v4) of the product that the request should use. Send it explicitly when the authenticated user has more than one product or when the integration must select a specific product. If omitted and the endpoint does not require it, the API uses the authenticated user's default product.
-
-**x-product-target-user-uuid** string
-
-UUID (v4) of the user on whose behalf the request should run within the selected product. If omitted, the request runs as the authenticated user. Requires x-product-uuid.
-
-## Responses[](#responses "Direct link to Responses")
-
-- 200
-- 400
-- 401
-- 422
-
-The operations returned successfully.
-
-- application/json
-
-- Schema
-- Example (from schema)
-
-**Schema**
-
-**page** numberrequired
-
-Page number.
-
-**page\_size** numberrequired
-
-Page size.
-
-**page\_total** numberrequired
-
-Page total.
-
-**total** numberrequired
-
-Total of elements.
-
-**data** object\[\]required
-
-Operations data.
-
-- Array \[
-
-
-**id** stringrequired
-
-Operation id.
-
-**fee** number
-
-Operation fee in cents.
-
-**state** stringrequired
-
-**Possible values:** \[`accepted`, `declined`, `undone`, `pending`, `reverted`, `waiting_accept`, `waiting_revert`, `waiting_ledger`, `waiting_credit`, `waiting_debit`, `waiting_accept_credit`\]
-
-Operation state.
-
-**description** stringrequired
-
-Operation description.
-
-**value** number
-
-Operation value in cents.
-
-**created\_at** date-timerequired
-
-Operation created at.
-
-**reverted\_at** date-time
-
-Operation reverted at.
-
-**currency\_id** numberrequired
-
-Currency Id.
-
-**currency\_symbol** stringrequired
-
-Currency symbol.
-
-**transaction\_id** numberrequired
-
-Transaction id.
-
-**transaction\_tag** stringrequired
-
-Transaction tag.
-
-**owner\_wallet\_uuid** string
-
-Operation owner wallet.
-
-**beneficiary\_wallet\_uuid** string
-
-Operation beneficiary wallet uuid.
-
-**operation\_ref\_id** string
-
-Operation ref id.
-
-**chargeback\_id** string
-
-Operation chargeback id.
-
-- \]
-
-
-```
-{ "page": 1, "page_size": 20, "page_total": 20, "total": 100, "data": [ { "id": "f6e2e084-29b9-4935-a059-5473b13033aa", "fee": 0, "state": "accepted", "description": "string", "value": 1880000, "created_at": "2026-03-26T14:02:58.523Z", "reverted_at": "2026-03-26T14:02:58.523Z", "currency_id": 2, "currency_symbol": "R$", "transaction_id": 2, "transaction_tag": "BRL", "owner_wallet_uuid": "f6e2e084-29b9-4935-a059-5473b13033aa", "beneficiary_wallet_uuid": "f6e2e084-29b9-4935-a059-5473b13033aa", "operation_ref_id": "f6e2e084-29b9-4935-a059-5473b13033aa", "chargeback_id": "f6e2e084-29b9-4935-a059-5473b13033aa" } ]}
-```
-
-If any required params are missing or has invalid format or type.
-
-User authentication failed.
-
-If any required params are missing or has invalid format or type.
-
-Loading...
-
-[
-
-Previous
-
-List Currencies
-
-](/baas/endpoints/v-1-get-all-currency-rest-controller-execute-v-1)[
-
-Next
-
-Get Operation by ID
-
-](/baas/endpoints/v-1-get-operation-by-id-rest-controller-execute-v-1)
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 148.7s)
-
-_Thinking:_
-
-**Analyzing Z.ro Bank Docs**
-
-The user is looking at Z.ro Bank for potential services, so I need to go over their documentation to identify what’s necessary for our product. Since we’re in read-only mode, I won’t make edits, but I’ll create a thorough analysis based on my research. I’ll map out what’s essential versus optional, highlighting any limitations. It could be helpful to specify APIs, onboarding flows, and perhaps ask if they want a comparison with other services.
-
-_Thinking:_
-
-**Finalizing Requirements for Z.ro**
-
-I need to summarize our next steps based on both the repository docs and the user’s request. Since we’re a documentation-first startup, I’ll synthesize our current product requirements with Z.ro's capabilities. It’s important to deeply examine all findings. Our phase 1 product includes payment-linked commission calculations, instant access to earned balances, partner-led custody, Pix instant transfers, dashboards, and an internal ledger. We’ll use payment events as our source of truth and start in Brazil, considering cards later. Now I'll analyze Z.ro's documentation.
-
-_Thinking:_
-
-**Considering payment integration**
-
-I’m weighing the option of gateway and merchant onboarding to make Z.ro the payment acceptance source of truth. That feels like a significant decision. For version one, maybe this isn't essential since we could just take payment events from the employers' existing processor. However, if we want to proceed with Z.ro for acceptance, we’ll likely need to focus on merchant onboarding, gateway integrations like QR codes, and webhooks, possibly considering Dock acquiring if cards are involved.
-
-_Thinking:_
-
-**Evaluating payment solutions**
-
-I’m considering a Brazil-first approach with Pix-based earnings access, possibly starting without merchant acceptance. Using Z.ro for collection is optional for version one. If we want payment-linked truth via Pix, a PaaS split QR code could route sales directly to the employer and employee. However, I realize that relying on Z.ro for split payments as the commission ledger might introduce challenges, such as complexity in commission logic and conflicts with reserves. So, we’ll need our own engine and internal ledger.
-
-_Thinking:_
-
-**Assessing initial payment structure**
-
-I may consider using split payments for simple cases later, but likely not for the initial core of the project. It's important to note what Z.ro cannot replace, including the commission rules engine, internal ledger for financial tracking, employer analytics, product UI/UX, and workflows for disputes and adjustments. We should evaluate the necessity of using full employee bank accounts from day one, as BaaS allows for onboarding and bank account retrieval for employees. Having employee wallets at Z.ro might be beneficial for our model, especially for instant payout access.
-
-_Thinking:_
-
-**Exploring payout models**
-
-I'm considering a couple of payout models. One option is to have employer funds in a master settlement account; when the commission is available, we transfer funds to employee sub-wallets through an internal P2P transfer, allowing employees to withdraw via Pix. The second option involves direct Pix payouts from the employer or platform account to the employee’s external Pix key without setting up Z.ro accounts for employees. I need to confirm what Z.ro supports regarding these BaaS Pix payments and whether I can execute actions on behalf of users.
-
-_Thinking:_
-
-**Considering Z.ro architecture options**
-
-I'm looking at the recommended architecture and thinking about using Z.ro BaaS as our main partner for various functions like onboarding and wallet issuance. Z.ro PaaS might be optional unless we want specific features like Pix collection APIs or dynamic QR codes at scale. As for Z.ro Gateway, it would only be necessary if we want them to handle our payment acceptance. However, for version 1, we might not need it since we can use existing processors.
-
-_Thinking:_
-
-**Mapping onboarding processes**
-
-I need to clearly outline the exact endpoints and processes for each onboarding module, focusing on KYB and KYC. For example, there are distinct steps for both legal person and natural person onboarding, including creating user accounts and uploading necessary documents.
-
-I should also mention document requirements, such as file types and size limits. Additionally, the user is looking for specific details on required artifacts, so I want to make sure I provide a thorough and clear list.
-
-_Thinking:_
-
-**Clarifying product requirements**
-
-I need to clarify the role of x-product-uuid in our endpoints, as it's either required or optional. It seems to relate to the Z.ro concept for white-labeling, which is key for provisioning products on our platform. We should also be using x-product-target-user-uuid to manage actions on behalf of employers or employees.
-
-It's important to mention the provisioning necessities, including sandbox and production setups, master accounts, webhooks, and sub-account capabilities. Lastly, I need to confirm with Z.ro how the white-label product and sub-account model function, especially regarding fund ownership.
-
-_Thinking:_
-
-**Examining webhook options and transactions**
-
-I'm looking into webhook authentication options for BaaS and PaaS. I see they mention optional credentials, and Gateway supports OAuth2 client credentials.
-
-Next, I’m curious about how refunds and chargebacks are represented and whether funds can be frozen or held. I also need to figure out the production base URL, which isn’t public.
-
-Further, I’ll consider fees, settlement arrangements, and if the split QR feature can support dynamic adjustments or holds. Lastly, I wonder about the payment processing roles for employers and Z.ro. These seem like contract questions not really answered in the docs.
-
-_Thinking:_
-
-**Evaluating API options**
-
-I’ve already looked at the decode endpoint. It seems like we might not need anything more. I’m thinking the direct creation using the pix key endpoint could clarify requirements. However, it might be enough as is. I could mention the decode step and then the create payment endpoint, but I’m also considering whether that's really necessary in the final output. It's all about balancing what adds value without overcomplicating things!
-
-_Thinking:_
-
-**Exploring financial infrastructure needs**
-
-I need to clarify that Z.ro can cover "most regulated money movement pieces" rather than "most product pieces." I think I might phrase it as: "Z.ro could be our main financial infrastructure partner for v1 if we retain our commission logic and ledger." Specifically, we would require BaaS first, with Gateway and PaaS as optional. I should cite the exact endpoints, but without overwhelming details. It's also important to mention "Dock" in the context of merchant onboarding.
-
-_Thinking:_
-
-**Analyzing card issuance requirements**
-
-I should consider that card issuance might involve third parties, which is useful to know if we're looking for a simpler vendor structure or direct control. I need to highlight the distinction between "What Z.ro docs explicitly expose" and "what docs do not prove." For example, public documents lack details on settlement schedules, fee tables, and other critical information, which requires diligence. Also, I think it's important to mention using their split QR only for straightforward commission disbursements and not as the sole source of truth.
-
-_Thinking:_
-
-**Structuring insights for Z.ro**
-
-I've identified some important insights. I think it’s necessary to mention concepts like "automatic receiver limits" or "scheduled payments," but they might not be crucial.
-
-The potential structure could be a top-line conclusion followed by specific needs from Z.ro. This includes setting up a BaaS product, onboarding legal and natural persons, establishing a wallet/account model, and integrating specific functionalities like Pix rails and reporting endpoints. Additionally, if Z.ro is to handle payments, we’d need aspects like merchant onboarding and QR generation. Lastly, I should note gaps or unknowns to confirm with Z.ro before moving forward.
-
-_Thinking:_
-
-**Listing onboarding requirements**
-
-I should create a clear list of documents required for onboarding and necessary data fields. Under "Required from us," I’d note steps for Z.ro commercial onboarding like registering for API access, obtaining API credentials, and configuring webhooks. For each employer's KYB process, I’m thinking of what details to collect, such as CNPJ, address, revenue, and shareholder information, alongside KYC and AML policies. Each employee would need similar documentation for KYC too.
-
-It seems important to separate "What we need from them" and "What we need on our side." The user wants complete clarity, so I’ll make sure to provide both sets of requirements.
-
-_Thinking:_
-
-**Planning wallet/card roadmap**
-
-I’m thinking about the wallet/card roadmap and it looks good overall. I see that Pix payments and deposits are confirmed if the funds live at Z.ro, and internal P2P transfers are fine as long as they stay between master and sub-wallets. Also, payment acceptance via Gateway/PaaS is optional for v1, while card endpoints can be delayed for later. I aim for a structured but concise document, targeting around 800 to 1200 words, possibly with bold headers and no nested bullets. I might not need extensive code references or citations.
-
-_Thinking:_
-
-**Considering account structure nuances**
-
-I’m thinking about the possibility of using a master account with an internal ledger to track employer balances, which might eliminate the need for individual employer accounts. However, having separate accounts could improve employer control and auditability. It seems essential to clarify whether employer KYB is required if using a pooled master account. I shouldn't exaggerate, so I’ll mention that it likely depends on the custody model for onboarding employers and employees.
-
-_Thinking:_
-
-**Evaluating employee onboarding requirements**
-
-I’m considering the situation where we only want one-off Pix payouts to external accounts. I need to ask Z.ro if we can handle the end-recipient KYC ourselves, since the documentation doesn't clarify that. However, our roadmap indicates that employee onboarding through partner KYC is planned for months 2-5, so it seems necessary from a product standpoint. I can confirm that employee onboarding is indeed recommended for version 1 of the product, but maybe not from day one.
-
-_Thinking:_
-
-**Evaluating excluded modules**
-
-I'm listing the excluded modules like Crypto as a Service and Cross-border/eFX, while noting that Open Finance won't be available on day one. The white-label app might be an option to speed up UI later. It’s useful to mention that the API is strong but more geared towards partners than individual users, indicating some vendor dependency.
-
-I need to consider regulatory implications, including their payment institution license which could assist with Pix and digital accounts. However, we must handle our own labor and tax mapping for commissions. Z.ro deals with banking rails, not payroll issues.
-
-_Thinking:_
-
-**Highlighting product requirements**
-
-I should note that the BaaS documentation includes judicial block webhooks, which is important if we hold user accounts, as court orders can block them. We need our product to manage these events, though it might be a bit advanced to dive into under risks.
-
-Additionally, API requests need nonce and x-transaction-uuid for mutating endpoints, so we’ll need our own request-id/idempotency layer as part of engineering requirements.
-
-I could outline what we need from Z.ro in three areas: the commercial package, APIs/features, and data/docs from our users. In short, Z.ro can cover much of the regulated money movement stack for our Brazil v1.
-
-_Thinking:_
-
-**Considering BaaS setup**
-
-I'm thinking about the need for BaaS in this project. We might only require Gateway/PaaS if we want Z.ro to serve as the collection and payment acceptance source of truth. That's a key consideration. Additionally, I realize I have to build the commission engine, internal ledger, reserve logic, employer analytics, and the app itself. There’s quite a bit of groundwork to lay out!
-
-_Thinking:_
-
-**Outlining Z.ro requirements**
-
-I'm organizing the must-haves for Z.ro and I see several essential components. First, there's the BaaS product setup with white-labeling and necessary API credentials. Then, the custody/account layer for partner-led models needs to be established. Onboarding flows for employers and employees, along with Pix payout rails for payments, are also crucial. After that, internal funds movement and reconciliation processes must be built. If we want Z.ro to collect payments, the Gateway/PaaS will be needed too. Lastly, I'll have to develop the payment commission rules and the dashboard.
-
-_Thinking:_
-
-**Evaluating product requirements**
-
-I’m considering the need for "product_uuid," which seems required for certain endpoints if an authenticated user has multiple products. For the BaaS decode pix key endpoint, it’s definitely needed. It’s good to keep in mind that many endpoints mention "x-product-uuid" as optional, but we should probably use it frequently.
-
-Also, I’m curious about whether gateway webhooks can help with fraud signals by including payer KYC data. However, since it's not central, maybe it's not essential.
-
-I’ll double-check if PaaS supports dynamic split payments because the documentation only references static ones.
-
-_Thinking:_
-
-**Assessing document details**
-
-I can mention that the public docs show a static Pix split QR endpoint, but it only allows for percent or absolute account splits rather than earned, available, or settled logic. That’s nice to note! I should also mention that merchant onboarding requires registering a legal person as a commercial establishment at Dock Acquiring; this adds another dependency beyond Z.ro.
-
-While they do have a white-label application and internet banking, I think we might prefer our own employee/employer UX and commission logic. It could be a fallback for a faster MVP, but probably not the primary option.
-
-Z.ro can likely cover most of the regulated rails for our Brazil v1, but not the core commission product.
-
-| Need | Z.ro coverage | Required now? |
-| --- | --- | --- |
-| Partner-led custody, accounts, wallets | `BaaS` | Yes |
-| Employer KYB / legal entity onboarding | `BaaS` legal-person onboarding | Yes if employers will have Z.ro-backed accounts/wallets |
-| Employee KYC / user onboarding | `BaaS` natural-person onboarding | Yes for our current roadmap |
-| Instant payout via `Pix` | `BaaS` Pix payments / deposits / devolutions | Yes |
-| Internal money movement between wallets | `BaaS` P2P transfers | Yes |
-| Balance, ops, reconciliation, statements | `BaaS` operations / reports / balance webhooks | Yes |
-| Customer payment collection via Pix/cards | `Gateway` or `PaaS` | Optional for v1 |
-| Split collection at payment time | `PaaS` static split Pix QR | Optional, not a ledger substitute |
-| Cards / stored balance spend | `BaaS` card endpoints | Later |
-| Commission rules engine, ledger, reserves, analytics | Not provided by Z.ro | We build this |
-
-**What we need from Z.ro**
-- A `BaaS` product setup for our white-label product, including sandbox access, production access, `API ID`, `API Key`, and the `product_uuid` their APIs expect.
-- A custody/account model: ideally one master product plus employer/employee users and wallets, using `x-product-uuid`, `x-product-target-user-uuid`, and `x-wallet-uuid`.
-- Employer onboarding flow:
- - `POST /users/accounts`
- - `POST /users/onboarding/legal-person`
- - shareholders
- - legal representatives
- - representative documents
- - company documents
- - finalize onboarding
-- Employee onboarding flow:
- - `POST /users/accounts`
- - `POST /users/onboardings`
- - document upload
- - onboarding status / webhook handling
-- Outbound `Pix` payout flow for employee cash-out.
-- Internal wallet transfer flow via `POST /v1/operations/p2p-transfers`.
-- Reconciliation and operations visibility via wallet, operations, statements, and webhook events.
-- Webhook registration with their team for onboarding status, deposits, payments, devolutions, and balance updates.
-
-**What we need to provide**
-- Our company onboarding to Z.ro and commercial setup.
-- For each employer:
- - CNPJ
- - address and revenue
- - shareholders
- - legal representatives
- - representative docs: selfie, ID, qualification declaration
- - company docs: social contract and balance sheet or revenue statement
-- For each employee:
- - CPF
- - address
- - nationality / PEP info
- - selfie
- - RG/CNH or digital identity
-- Engineering work:
- - HTTPS webhook endpoints
- - bearer-token auth flow from `API ID` + `API Key`
- - `nonce` and `x-transaction-uuid` generation
- - idempotent webhook/event processing
-
-**What we do not need from Z.ro now**
-- Crypto
-- Cross-border / eFX
-- Open Finance
-- White-label app
-- Card issuance on day one
-
-**When we would also need `Gateway` or `PaaS`**
-- If we want Z.ro to also be the payment-acceptance layer, not just the payout/custody layer.
-- If we want employers to collect customer payments through Z.ro Pix QR or card acquiring.
-- If we want their payment webhooks to become the sale/payment source of truth.
-
-**Important constraint**
-- Their public docs do show a split Pix QR endpoint in `PaaS`, but it is a simple account split on a static QR.
-- That is not enough for our core model.
-- We still need our own commission engine and internal ledger with `earned`, `available`, and `settled`, plus reserves, clawbacks, disputes, and employer analytics.
-
-**Best fit recommendation**
-- Use Z.ro as a `BaaS-first` partner.
-- Contract for:
- - KYB/KYC
- - wallets/accounts
- - internal transfers
- - `Pix` payouts
- - reconciliation webhooks
-- Treat `Gateway` / `PaaS` as optional unless we explicitly want to own payment collection from day one.
-
-**Questions to resolve with Z.ro before committing**
-- Can one master product hold funds and create segregated employer/employee wallets, or must every employer have its own full legal-person account?
-- Can employees cash out via `Pix` without a full Z.ro account, or is user onboarding mandatory for our use case?
-- What are production limits, fees, payout SLAs, and webhook guarantees?
-- How do refunds/devolutions interact with already-moved employee balances?
-- If we use Gateway, does each employer need separate merchant onboarding at Dock Acquiring?
-
-If useful, I can turn this into a Z.ro diligence checklist or compare this setup directly against `Dock`, `QI Tech`, and `Celcoin`.
-
----
-
-## User
-
-compare this setup with other potential partners like Dock and Celcoin. The idea I envisioned at first was just using their BaaS and maybe their PaaS.
-
----
-
-## Assistant (Plan · GPT-5.4 · 16.9s)
-
-_Thinking:_
-
-**Exploring partner comparisons**
-
-I need to help the user compare their setup with potential partners like Dock and Celcoin. They mentioned initially considering their BaaS and possibly PaaS. Since I’m in plan mode, I probably should research the public documentation for Dock and Celcoin to compare it with Z.ro.
-
-I’m thinking about using webfetch and perhaps Context7 for any relevant documents. It might be useful to execute multiple webfetch calls to gather the necessary information. I’ll check the docs in the repository for additional insights as well.
-
-_Thinking:_
-
-**Comparing service capabilities**
-
-I’m considering using webfetch to gather public documentation for potential partners like Dock and Celcoin. It’s essential to identify their capabilities for BaaS/PaaS, KYB/KYC, and other services. I want to compare the user’s setup, likely Z.ro’s BaaS and possibly PaaS, against these partners.
-
-It seems important to tailor this to our product needs, including commission infrastructure in Brazil. I might also need to check if QI Tech is relevant here, though the focus should remain on Dock and Celcoin. I’ll start by researching their documentation and product pages.
-
-_Thinking:_
-
-**Analyzing BaaS and PaaS capabilities**
-
-I need to note the user’s idea of utilizing their BaaS and possibly PaaS. It’s important to analyze whether this combination is sufficient for each partner and what additional components we might need to develop. I want to identify if Dock offers Banking as a Service along with Pix, card capabilities, and accounts. On the other hand, Celcoin provides BaaS, APIs, and Pix/payment collection.
-
-I’m wondering if Z.ro is less mature in comparison with Dock and Celcoin, so I'll need to research this more thoroughly and keep the user updated on my findings before moving forward.
-
-Comparing Z.ro against Dock and Celcoin on the specific stack we need: BaaS first, optional payment acceptance layer, and how much of the commission-flow infrastructure we still have to build ourselves.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://dock.tech/en/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Dock - Spread financial power
-
-
-
-
-
-
-
-
-
-[Dock](https://dock.tech/en/)
-
-[Dock](#!) [Solutions](#!) [Developers](https://developers.dock.tech/) [Content](https://dock.tech/en/fluid/) [Contact](#!)
-
-[](# "click to search")
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-**Dock**
-
-Over 25 years dedicated to democratizing access to financial services.
-
-[About](https://dock.tech/en/about/)
-
-We’re reshaping the financial landscape to empower society.
-
-[Career in Dock](https://dock.tech/en/career/)
-
-Maximize your potential without borders; create innovative solutions for leading brands.
-
-[Press room](https://dock.tech/en/press-room/)
-
-Communicating our true impact and commitment to financial inclusion. Access news and official resources.
-
-**Solutions**
-
-Leverage Brazil's largest portfolio of financial solutions to expand and strengthen your business.
-
-[Banking](https://dock.tech/en/solution/banking)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Cards & Credit](https://dock.tech/en/solution/cards-credit)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Acquiring](https://dock.tech/en/solution/acquiring)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Dock One](https://dock.tech/en/dock-one/)
-
-A comprehensive platform to scale your operations with global reach.
-
-[LATAM Solutions](https://dock.tech/en/solutions-dock-latam/)
-
-Drive innovation and grow your business.
-
-[Solutions Brazil](#!)
-
-Discover the most complete portfolio of financial services.
-
-[Dock One platform](https://dock.tech/en/dock-one/)
-
-A complete platform to scale your operations with global reach.
-
-[Banking](https://dock.tech/en/solution/banking)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Cards & Credit](https://dock.tech/en/solution/cards-credit)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Acquiring](https://dock.tech/en/solution/acquiring)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Dock One](https://dock.tech/en/dock-one/)
-
-A comprehensive platform to scale your operations with global reach.
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/multi-benefit-card/) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado) [Tokenization](https://dock.tech/en/tokenization/)
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-[LATAM Solutions](https://dock.tech/en/solutions-dock-latam/) [Dock Colombia](https://dock.tech/en/countries/colombia/) [Dock Mexico](https://dock.tech/en/countries/mexico/)
-
-[Banking](https://dock.tech/en/solution/banking) [Cards & Credit](https://dock.tech/en/solution/cards-credit) [Acquiring](https://dock.tech/en/solution/acquiring) [Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/multi-benefit-card/) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado) [Tokenization](https://dock.tech/en/tokenization/)
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-**Contact**
-
-We are prepared to serve you in the best possible way.
-
-[Speak to the salesperson](https://dock.tech/en/#contato)
-
-To get in touch with our sales team, click here and complete the form.
-
-[Customer service](https://dock.tech/en/sac/)
-
-For frequently asked questions and customer service, click here.
-
-[Media Inquiries](https://dock.tech/en/press-room/#contato-imprensa)
-
-Please reach out to our communications team.
-
-[Dock](https://dock.tech/en/)
-
-[
-
-
-
-
-
-
-
-](#!)
-
-[Dock](#!) [Solutions](#!) [Developers](https://developers.dock.tech/) [Content](https://dock.tech/en/fluid/) [Contact](#!)
-
-[Dock](#!)
-
-Over 25 years dedicated to democratizing access to financial services.
-
-[About](https://dock.tech/en/about/)
-
-We’re reshaping the financial landscape to empower society.
-
-[Career in Dock](https://dock.tech/en/career/)
-
-Maximize your potential without borders; create innovative solutions for leading brands.
-
-[Press room](https://dock.tech/en/press-room/)
-
-Communicating our true impact and commitment to financial inclusion. Access news and official resources.
-
-[Solutions](#!)
-
-Leverage Brazil's largest portfolio of financial solutions to expand and strengthen your business.
-
-[Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Discover our platform](#!) [LATAM Solutions](#!) [Solutions Brazil](#!) [Dock One platform](#!) [Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Discover our platform](#!)
-
-[LATAM Solutions](#!)
-
-Drive innovation and grow your business.
-
-[LATAM Solutions](https://dock.tech/en/es/solutions-dock-latam/)
-
-[Solutions Brazil](#!)
-
-Discover the most complete portfolio of financial services.
-
-[Banking](https://dock.tech/en/solution/banking) [Cards & Credit](https://dock.tech/en/solution/cards-credit) [Acquiring](https://dock.tech/en/solution/acquiring) [Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-[Banking](#!)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Cards & Credit](#!)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/#cartao-multibeneficio) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado)
-
-[Acquiring](#!)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Fraud Prevention](#!)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[our platform](#!)
-
-A comprehensive platform to scale your operations with global reach.
-
-
-
-
-
-DOCK ONE **Our layered solutions**
-
-Robust high-tech platform, totalmente personalized and modular thanks to our APIs, in addition to taking care of all the bureaucracy, IT, products, regulatory, licensing and prevention of fraude.
-
-[LEARN MORE](https://dock.tech/en/dock-one)
-
-[Contact](#!)
-
-We are prepared to serve you in the best possible way.
-
-[Talk to Commercial](https://dock.tech/en/#contato)
-
-To get in touch with our sales team, click here and complete the form.
-
-[Customer Service](https://dock.tech/en/sac/)
-
-For frequently asked questions and customer service, click here.
-
-[Media Inquiries](https://dock.tech/en/press-room/#contato-imprensa)
-
-Please reach out to our communications team.
-
-# The most complete financial services infrastructure
-for your business
-
-Offer digital accounts, cards with your brand and innovate in payment method services with Pix and acquisition. All with security and prevention fraude.
-
-[LEARN MORE](#contato "click to access")
-
-Your browser does not support the video tag.
-
-## Spread financial power
-
-Be part of the greatest transformation ever seen in financial services and boost your business by spreading financial power around the world.
-
-### Dock One platform
-
-Explore our cloud-native platform, the largest and most comprehensive in Latin America, and discover our solutions.
-
-[Learn more](https://dock.tech/en/dock-one/ "Click and learn more")
-
-
-
-
-
-### Banking
-
-Elevate the customer experience and increase your profitability with financial solutions integrated into your core business.
-
-[Learn more](https://dock.tech/en/solution/banking/ "Click and learn more")
-
-
-
-
-
-### Cards & Credit
-
-Offer personalized cards with your brand from major networks, while we take care of the entire operation.
-
-[Learn more](https://dock.tech/en/solution/cards-credit "Click and learn more")
-
-
-
-
-
-### Acquiring
-
-Have your own white-label acquiring solution using our technology to ensure simplicity and speed in your go-to-market.
-
-[Learn more](https://dock.tech/en/solution/acquiring "Click and learn more")
-
-
-
-
-
-### Fraud Prevention
-
-Reduce end-to-end risk in your banking, cards, or acquiring business model through solutions that cover everything - from customer onboarding to transaction monitoring.
-
-[Learn more](https://dock.tech/en/solution/fraud-prevention/ "Click and learn more")
-
-
-
-
-
-### Leader in financial technology in Latin America.
-
-If part of the biggest revolution ever seen in financial services, discover how our integrated solutions can boost your business.
-
-[Discover our solutions](https://dock.tech/en/solutions-dock-latam/ "Click and learn more")
-
-
-
-
-
-### Dock One platform
-
-Explore our cloud native platform, the largest and most complete in Latin America, and discover our solutions.
-
-[LEARN MORE](https://dock.tech/en/es/dock-one/ "Click and learn more")
-
-Your browser does not support the video tag.
-
-### Dock One platform
-
-Explore our cloud-native platform, the largest and most comprehensive in Latin America, and discover our solutions.
-
-[Learn more](https://dock.tech/en/dock-one/ "Click and learn more")
-
-
-
-
-
-### Banking
-
-Elevate the customer experience and increase your profitability with financial solutions integrated into your core business.
-
-[Learn more](https://dock.tech/en/solution/banking/ "Click and learn more")
-
-
-
-
-
-### Cards & Credit
-
-Offer personalized cards with your brand from major networks, while we take care of the entire operation.
-
-[Learn more](https://dock.tech/en/solution/cards-credit "Click and learn more")
-
-
-
-
-
-### Acquiring
-
-Have your own white-label acquiring solution using our technology to ensure simplicity and speed in your go-to-market.
-
-[Learn more](https://dock.tech/en/solution/acquiring "Click and learn more")
-
-
-
-
-
-### Fraud Prevention
-
-Reduce end-to-end risk in your banking, cards, or acquiring business model through solutions that cover everything - from customer onboarding to transaction monitoring.
-
-[Learn more](https://dock.tech/en/solution/fraud-prevention/ "Click and learn more")
-
-
-
-
-
-## Rely on over 20 years of experience from the true one-stop shop in financial services
-
-
-
-
-
-CARDS **R$ 1,4 trillion**
-
-processed annually.
-
-
-
-
-
-CARDS
-
-Issuer of **credit, debit and
-prepaid cards**
-
-
-
-
-
-COMPLETE PLATFORM **56**
-
-is the number of financial transactions processed by Dock while you read this card
-
-
-
-
-
-DIGITAL ACCOUNT **70**
-
-million active accounts in the last 30 days
-
-
-
-
-
-DOCK **Present in 11 countries**
-
----
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**Regulated PI and direct participant in Pix** (bank code #301)
-
-**La evolución de la tecnología financiera en América Latina.**
-
-
-
-
-
-PIX **1,3**
-
-billion Pix carried out in the last 12 months
-
----
-
-
-
-
-
-DOCK **400+**
-
-Market-leading companies trust Dock
-
-
-
-
-
-ACQUIRING **30+**
-
-certified networks: Visa ... + 30 networks
-
-
-
-
-
----
-
-
-
-
-
-BANKING
-
-**Provider** Infrastructure provider for payments and banking
-
-**Provider** Infrastructure provider for payments and banking
-
-**Proveedor** de infraestructura de pagos con un conjunto completo de soluciones.
-
-
-
-
-
-DOCK ONE **Our layered solutions**
-
-Robust high-tech platform, totalmente personalized and modular thanks to our APIs, in addition to taking care of all the bureaucracy, IT, products, regulatory, licensing and prevention of fraude.
-
-
-
-
-
-ACQUIRING **30+**
-
-certified networks: Visa ... + 30 networks
-
-
-
-
-
----
-
-
-
-
-
-BANKING **Provider**
-
-Infrastructure provider for payments and banking
-
-
-
-
-
-DOCK ONE **Our layered solutions**
-
-Robust high-tech platform, totalmente personalized and modular thanks to our APIs, in addition to taking care of all the bureaucracy, IT, products, regulatory, licensing and prevention of fraude.
-
-
-
-
-
-PIX **1,3**
-
-billion Pix carried out in the last 12 months
-
-
-
-
-
-CARDS **R$ 1,4 trillion**
-
-processed annually.
-
-
-
-
-
-CARDS
-
-Issuer of **credit, debit and prepaid**
-
-
-
-
-
-COMPLETE PLATFORM **56**
-
-is the number of financial transactions processed by Dock while you read this card
-
-
-
-
-
-DIGITAL ACCOUNT **70**
-
-million active accounts in the last 30 days
-
-
-
-
-
-DOCK **Present in 11 countries**
-
----
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**Regulated PI and direct participant in Pix** (bank code #301)
-
-**La evolución de la tecnología financiera en América Latina.**
-
-**
-
-
-
-
-
-DOCK **400**
-
-Customers approximately
-
-
-
-**
-
- **
-
-
-
-## Reliability and security for your transactions
-
-When you choose Dock, you're not just selecting a service; you're choosing a partner dedicated to driving your success.
-
-
-
-
-
-### Regulated Payment Institution and Direct Pix Participant
-
-Peace of mind knowing your payments are in good hands, with full security and legal backing.
-
-
-
-
-
-### VISA, MasterCard, Elo Licenses
-
-Accept the leading card networks in the market and offer more options to your customers.
-
-
-
-
-
-### Adaptable Global Payment Platform
-
-Reach customers worldwide and tailor the experience to meet their needs.
-
-
-
-
-
-### Comprehensive Infrastructure
-
-A complete solution for online payments, including gateway, fraud prevention, and risk management.
-
-
-
-
-
-### Recognized Certifications
-
-Commitment to security, quality, and international compliance across all our operations.
-
-
-
-
-
-### Fraud Prevention
-
-Data and transactions protected with the best tools on the market.
-
-##### Check out the companies that trust our solutions
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## Explore Embedded Finance with Dock
-
-Transform your company into a leader in the digital financial market, offering a revolutionary experience for your customers.
-
-
-
-
-
-### Why choose Dock?
-
-Our expertise and technology enable your company to **promote financial inclusion**, turning customers into active participants and empowering the global economy. We are ready to help **transform your business and make a positive impact**.
-
-
-
-
-
-### What is Embedded Finance?
-
-Imagine your company not only offering its usual products but also **integrated financial services**. Your platform becomes a financial hub, providing everything from payments to loans, **all within the digital environment**.
-
-[LEARN MORE](https://conteudo.dock.tech/embedded-finance "Click and learn more")
-
-[LEARN MORE](https://conteudo.dock.tech/embedded-finance-en "Click and learn more")
-
-[LEARN MORE](https://conteudo.dock.tech/embedded-finance-es "Click and learn more")
-
-
-
-
-
-### How does Dock drive this transformation?
-
-Dock leads in financial services, providing the **infrastructure for companies to expand their business**. With our integrated and white-label platform, we help launch customized financial solutions, with seamless integration and agile deployment, combining **innovation and efficiency**.
-
-## Content and events to go further
-
-Discover our exclusive content and events that will unlock even more business potential.
-
-## Content and events to go further
-
-Discover our exclusive content and events that will unlock even more business potential.
-
-## Contents and events to go further
-
-Discover our exclusive content and events that will unlock even more of your business potential.
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/cards-et-credit/alternative-data/ "Alternative data: how new sources of information are transforming the financial system and credit analysis.")
-
-[
-
-Cards & Credit
-
-## Alternative data: how new sources of information are transforming the financial system and credit analysis.
-
-](https://dock.tech/en/fluid/blog/cards-et-credit/alternative-data/ "Alternative data: how new sources of information are transforming the financial system and credit analysis.")[LEARN MORE](https://dock.tech/en/fluid/blog/cards-et-credit/alternative-data/)
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/financial/fintechs-in-Mexico/ "Fintechs in Mexico: trends, opportunities, and challenges in one of the most dynamic scenarios in Latin America.")
-
-[
-
-Financial Universe
-
-## Fintechs in Mexico: trends, opportunities, and challenges in one of the most dynamic scenarios in Latin America.
-
-](https://dock.tech/en/fluid/blog/financial/fintechs-in-Mexico/ "Fintechs in Mexico: trends, opportunities, and challenges in one of the most dynamic scenarios in Latin America.")[LEARN MORE](https://dock.tech/en/fluid/blog/financial/fintechs-in-Mexico/)
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")
-
-[
-
-Banking
-
-## How to stand out in the financial services sector in a context of multi-banking.
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/multi-banking/)
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/cards-et-credit/card-processing/ "Card processing and payment methods: what are the trends and how to offer the best customer experience?")
-
-[
-
-Cards & Credit
-
-## Card processing and payment methods: what are the trends and how to offer the best customer experience?
-
-](https://dock.tech/en/fluid/blog/cards-et-credit/card-processing/ "Card processing and payment methods: what are the trends and how to offer the best customer experience?")[LEARN MORE](https://dock.tech/en/fluid/blog/cards-et-credit/card-processing/)
-
-[
-
-
-...29159 bytes truncated...
-
-The tool call succeeded but the output was truncated. Full output saved to: /home/alex/.local/share/opencode/tool-output/tool_d6250e0070012Wb0Zf6aFXFuV8
-Use the Task tool to have explore agent process this file with Grep and Read (with offset/limit). Do NOT read the full file yourself - delegate to save context.
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.celcoin.com.br/en/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-
-
- Infraestrutura financeira: Banking, Credit, Payments, Regulatory | Celcoin
-
-[](https://www.celcoin.com.br)
-
-- Soluções
-
- Close Soluções Open Soluções
-
- cel\_bricks Plataformas mybenk Open Finance
-
- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-
- Saiba mais como o Embedded Finance da Celcoin pode apoiar o seu negócio.
-
- 
-
- - [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-
- - [BaaS](https://www.celcoin.com.br/cel_banking/banking-as-a-service/)
- - [Banco Liquidante](https://www.celcoin.com.br/cel_banking/banco-liquidante/)
- - [Cartão White Label](https://www.celcoin.com.br/cel_banking/cartao-white-label/)
- - [Compartilhamento de Dados](https://www.celcoin.com.br/cel_banking/compartilhamento-de-dados/)
- - [Core Banking](https://www.celcoin.com.br/cel_banking/core-banking/)
- - [Open Insurance](https://www.celcoin.com.br/cel_banking/open-finance-insurance/)
- - [Regulatório](https://www.celcoin.com.br/cel_banking/regulatorio/)
-
- - [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-
- - [Débito Veicular](https://www.celcoin.com.br/cel_payments/debito-veicular/)
- - [Débito Veicular White Label](https://www.celcoin.com.br/cel_payments/debito-veicular-white-label/)
- - [Gateway de Pagamento](https://www.celcoin.com.br/cel_payments/gateway-de-pagamento/)
- - [ITP](https://www.celcoin.com.br/cel_payments/open-finance-itp/)
- - [Pagamento de contas](https://www.celcoin.com.br/cel_payments/pagamento-de-contas/)
- - [Pix](https://www.celcoin.com.br/cel_payments/pix/)
- - [Recargas](https://www.celcoin.com.br/cel_payments/recargas/)
- - [Saque e Depósito](https://www.celcoin.com.br/cel_payments/saque-e-deposito/)
-
- - [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-
- - [CCB](https://www.celcoin.com.br/cel_credit/ccb/)
- - [Consignado as a Service](https://www.celcoin.com.br/cel_credit/consignado-as-a-service/)
- - [Conta Escrow](https://www.celcoin.com.br/cel_credit/conta-escrow/)
- - [Core Credit](https://www.celcoin.com.br/cel_credit/core-credit/)
- - [Gestão de Carteira e Cobrança](https://www.celcoin.com.br/cel_credit/gestao-de-carteira-e-cobranca/)
- - [Nota Comercial](https://www.celcoin.com.br/cel_credit/nota-comercial/)
-
- [Plataforma de Antecipações](https://www.celcoin.com.br/plataforma-de-antecipacoes/)
-
- Uma plataforma moderna para antecipação de recebíveis com toda a infraestrutura regulatória, tecnológica e operacional da Celcoin.
-
- [Ver solução](https://www.celcoin.com.br/plataforma-de-antecipacoes/)
-
- 
-
- [mybenk](https://www.celcoin.com.br/mybenk/)
-
- Saiba mais como o mybenk pode apoiar a transformar o universo financeiro interno. Uma solução completa para todos seus stakeholders.
-
- [Ver solução](https://www.celcoin.com.br/mybenk/)
-
- 
-
- [Open Finance](https://www.celcoin.com.br/open-finance/)
-
- Todas as oportunidades do Open Finance para o seu negócio.
-
- 
-
- - [ITP](https://www.celcoin.com.br/cel_payments/open-finance-itp/)
- - [Pix Automático](https://www.celcoin.com.br/open-finance/pix-automatico/)
- - [Pix Inteligente](https://www.celcoin.com.br/open-finance/pix-inteligente/)
-
- - [Pix por Aproximação](https://www.celcoin.com.br/open-finance/pix-por-aproximacao/)
- - [Pix Biometria](https://www.celcoin.com.br/open-finance/pix-biometria/)
- - [Pix Recorrente](https://www.celcoin.com.br/open-finance/pix-recorrente/)
-
- - [Financial Data](https://www.celcoin.com.br/open-finance/financial-data/)
- - [Cadastro Expresso](https://www.celcoin.com.br/open-finance/cadastro-expresso/)
- - [Detentora de Conta](https://www.celcoin.com.br/open-finance/detentora-de-conta/)
-
-- Desenvolvedores
-
- Close Desenvolvedores Open Desenvolvedores
-
- Comece a integrar as soluções da Celcoin
-
- [Explorar soluções](https://www.celcoin.com.br/developers/)
-
- 
-
- Developer
-
- - [APIs](https://developers.celcoin.com.br/reference)
- - [Documentação](https://developers.celcoin.com.br/docs)
- - [Developers](https://www.celcoin.com.br/developers/)
- - [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-- Empresa
-
- Close Empresa Open Empresa
-
- Empresa
-
- - [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
- - [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
- - [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
- - [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
- [](https://www.celcoin.com.br/partners/)
-
-- Conteúdos
-
- Close Conteúdos Open Conteúdos
-
- CONTEÚDOS
-
- - [Eventos](https://www.celcoin.com.br/eventos/)
- - [Insights](https://www.celcoin.com.br/insights/)
- - [News](https://www.celcoin.com.br/news/)
- - [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
- Últimas novidades
-
- [ETFs: como funcionam e o que avaliar antes de investir](https://www.celcoin.com.br/news/investimento-em-etf/)
-
- 20 de March de 2026
-
- [Celcoin conquista certificação PCI DSS e reforça segurança como diferencial competitivo no mercado financeiro](https://www.celcoin.com.br/news/celcoin-recebe-certificacao-de-seguranca-pci-dss/)
-
- 19 de March de 2026
-
- [Mais de 60% dos consumidores abandonam suas compras após uma experiência negativa](https://www.celcoin.com.br/news/novo-comportamento-do-consumidor-no-varejo/)
-
- 19 de March de 2026
-
-
-[Entrar](#Login)
-
-Qual o seu painel na **Celcoin?**
-
-Cada painel tem sua credencial distinta.
-
-Não tem acesso? **Fale com um especialista**
-
-- cel\_bricks
-
-Acesse o Painel do Cliente para obter relatórios e simplificar a gestão financeira da sua empresa.
-
-- cel\_credit (escrow)
-
-Gerencie sua conta escrow com eficiência e praticidade.
-
-- Gateway de Pagamentos
-
-Gerencie suas finanças com eficiência e praticidade.
-
-Ainda não possui uma conta? **Cadastre-se**
-
-Qual o seu painel na **Celcoin?**
-
-Cada painel tem sua credencial distinta.
-
-- cel\_bricks
-
-- cel\_credit (escrow)
-
-- Gateway de Pagamento
-
-Não tem acesso?
-
-- Criar conta Celcoin (contratar)
-
-- Criar conta Gateway de Pagamento
-
-[Contratar](https://www.celcoin.com.br/contato-celcoin/)
-
-
-
-The best service for growth
-
-# Infratech financeira para potencializar negócios
-
-Oferecemos uma infraestrutura completa e pioneira para conectar empresas de todos os segmentos a oportunidades do mercado financeiro, com soluções incorporadas às necessidades de seus clientes. A partir de um novo conceito de Embedded Finance, tudo é feito de uma forma simples, rápida e sem burocracias, deixando toda a parte regulatória com a gente. Isso é Celcoin.
-
-[Fale com um especialista](https://www.celcoin.com.br/contato-celcoin/)
-
-cel\_bricks
-
-## Infraestrutura modularizada com soluções para alavancar seu negócio
-
- 
-
-### cel\_banking
-
-BaaS, Banco Liquidante, Cartão White Label, Compartilhamento de Dados, Open Insurance e Regulatório.
-
-### cel\_credit
-
-CCB, Conta Escrow, Gestão de Carteira e Cobrança, Nota Comercial e Onboarding.
-
-### cel\_payments
-
-Débito Veicular, Gateway de Pagamento, ITP, Pagamento de Contas, Pix, Recargas e Saque e Depósito.
-
-Clientes
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
-
-
-Praticidade
-
-## Experiência financeira mais integrada aos seus clientes e fluxos de receita
-
-- Integração completa com as diferentes plataformas de sua empresa e características.
-- Iniciador e detentor de contas de Open Finance e Participante Direto do Pix.
-- Licença do Banco Central (BC) para atuar como Instituição de Pagamento.
-- Infraestrutura de onboarding, compliance e regulatório.
-- Soluções Regulatórias para Instituições de Pagamento (IP) e Sociedades de Crédito Direto (SCD).
-
-Diferenciais Celcoin
-
-## Capacitando o crescimento acelerado no ecossistema financeiro
-
-Aceleração
-
-### Lançamento Rápido
-
-Módulos plug and play e arquitetura SaaS reduzem a complexidade do desenvolvimento e aceleram o lançamento de novos produtos financeiros, melhorando o tempo de geração de receita e a competitividade.
-
-### Arquitetura Modular em APIs
-
-Uma base ampla e a alta qualidade das nossas APIs garantem integrações mais rápidas, reduzindo custos de desenvolvimento e acelerando o go-to-market.
-
-### Experiência e Suporte ao Desenvolvedor
-
-Documentação clara, SDKs e ambientes de sandbox tornam a integração simples e ágil, encurtando ciclos de implementação e reduzindo custos de engenharia.
-
-Segurança
-
-### Prevenção de Fraudes e Controles de Risco
-
-Monitoramento inteligente em tempo real, com uso de IA e autenticação forte, garantindo segurança, reduzindo fraudes e mitigando riscos de compliance.
-
-### Compliance Nativo
-
-KYC, AML e relatórios regulatórios já integrados à infraestrutura reduzem riscos, simplificam auditorias e garantem conformidade total com as normas do Banco Central.
-
-Confiabilidade
-
-### Escalabilidade e Alta Disponibilidade
-
-Infraestrutura cloud-native, estável e de alta performance para sustentar picos de volume com segurança e confiança.
-
-### Ecossistema de Parceiros
-
-Uma rede sólida de bancos, redes de pagamento e fintechs amplia a cobertura de funcionalidades e acelera o acesso a novas oportunidades de negócio.
-
-Expansão
-
-### Distribuição White-Label e Embutida
-
-Nossa infraestrutura white-label permite que empresas ofereçam produtos financeiros com sua própria marca, ampliando a distribuição e reduzindo custos de aquisição de clientes.
-
-### Acesso e Personalização de Dados
-
-Dados do Open Finance e ferramentas de analytics possibilitam ofertas personalizadas, aumentando a conversão e a fidelização de clientes.
-
-### Cobertura dos Meios de Pagamento Locais
-
-Soluções que combinam pagamentos e crédito ampliam conversão, ARPU e fidelização, com total aderência às redes nacionais.
-
-[Conheça todos os diferenciais](https://www.celcoin.com.br/diferenciais-celcoin/)
-
-mybenk
-
-## Solução completa de banking e crédito para todos seus stakeholders
-
-### Aplicativo white label e internet banking
-
-Plataforma completa para todos os casos de usos de seus stakeholders com a marca de sua empresa e totalmente personalizável, garantindo acesso fácil a sua aplicação pela plataforma web ou app.
-
-[Saiba mais](https://www.celcoin.com.br/mybenk/)
-
- 
-
- 
-
-
-
-Plataforma completa para todos os casos de usos de seus stakeholders com a marca de sua empresa e totalmente personalizável, garantindo acesso fácil a sua aplicação pela plataforma web ou app.
-
-[Saiba mais](https://www.celcoin.com.br/mybenk/)
-
-### Painel backoffice
-
-Gerencie o seu ecossistema diretamente com nosso Painel do Cliente, com todos os relatórios necessários para checar a evolução do seu negócio.
-
-[Saiba mais](https://www.celcoin.com.br/mybenk/)
-
- 
-
-Nossos números
-
-## A Celcoin no mercado
-
-### +6 mil
-
-Clientes entre bancos digitais, fintechs, instituições financeiras e demais empresas.
-
-### +R$30 Bi
-
-Movimentados mensalmente.
-
-### +400 MM
-
-De transações mensais.
-
-Indústrias
-
-## Soluções financeiras para todos os segmentos
-
-Transformamos operações financeiras em estratégias de crescimento para sua indústria. Oferecemos tecnologia integrada e adaptável para modernizar processos, aumentar a eficiência e gerar novas oportunidades de receita.
-
-[Saiba mais](https://www.celcoin.com.br/industrias/)
-
- 
-
-## Potencialize seu negócio com o Embedded Finance da Celcoin
-
-Aumente agora seu potencial de negócio com nossa infraestrutura exclusiva para você.
-
-[Fale com um especialista](https://www.celcoin.com.br/contato-celcoin/)
-
-- [](https://www.linkedin.com/company/celcoin-financial-hub/)
-- [](https://www.instagram.com/celcoin_/)
-- [](https://x.com/celcoinbr)
-- [](https://www.youtube.com/channel/UCOz8tQnZl3cV4cI0beQ5pYw)
-
-Soluções
-
-- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-- [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-- [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-- [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-- [mybenk](https://www.celcoin.com.br/mybenk/)
-
-[Indústrias](https://www.celcoin.com.br/industrias/)
-
-- [E-commerce e Marketplace](https://www.celcoin.com.br/industrias/marketplace/)
-- [Mercado de Capitais](https://www.celcoin.com.br/industrias/mercado-de-capitais/)
-- [Varejo](https://www.celcoin.com.br/industrias/varejo/)
-
-- ERP
-- Insurance
-- Instituições financeiras
-- Utilities
-
-Empresa
-
-- [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
-- [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
-Recurso
-
-- [Canal de Denúncias](https://www.celcoin.com.br/canal-de-denuncias/)
-- [Compliance e Regulatório](https://www.celcoin.com.br/compliance-e-regulatorio/)
-- [Ouvidoria](https://www.celcoin.com.br/ouvidoria/)
-
-- [Seja um parceiro](https://www.celcoin.com.br/partners/)
-- [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
-- [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
-Conteúdos
-
-- [Eventos](https://www.celcoin.com.br/eventos/)
-- [Insights](https://www.celcoin.com.br/insights/)
-- [News](https://www.celcoin.com.br/news/)
-- [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
-Developers
-
-- [APIs](https://developers.celcoin.com.br/reference)
-- [Documentação](https://developers.celcoin.com.br/docs)
-- [Developers](https://www.celcoin.com.br/developers/)
-- [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-Atendimento Celcoin
-
-De segunda a sexta-feira: das 09h às 18h
-
-Telefone
-
-[(11) 5070-8153](tel:1150708153)
-
-Whatsapp
-
-[(11) 4765-5043](https://wa.me/551147655043)
-
-Suporte
-
-Suporte especializado para ajudar você a extrair o máximo das soluções Celcoin
-
-[Enviar uma solicitação](https://suporte.celcoin.com.br/hc/pt-br/requests/new)
-
-Ouvidoria
-
-De segunda a sexta-feira: das 09h às 17h
-
-Telefone
-
-[0800 591 1852](tel:08005911852)
-
-Soluções
-
-- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-- [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-- [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-- [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-- [mybenk](https://www.celcoin.com.br/mybenk/)
-
-Indústrias
-
-- [E-commerce e marketplace](https://www.celcoin.com.br/industrias/marketplace/)
-- [Mercado de capitais](https://www.celcoin.com.br/industrias/mercado-de-capitais/)
-- [Varejo](https://www.celcoin.com.br/industrias/varejo/)
-
-- ERP
-- Insurance
-- Instituições financeiras
-- Utilities
-
-Empresa
-
-- [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
-- [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
-Recurso
-
-- [Canal de Denúncias](https://www.contatoseguro.com.br/)
-- [Compliance e Regulatório](https://www.celcoin.com.br/compliance-e-regulatorio/)
-- [Ouvidoria](https://www.celcoin.com.br/ouvidoria/)
-
-- [Seja um parceiro](https://www.celcoin.com.br/partners/)
-- [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
-- [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
-Conteúdos
-
-- [News](https://www.celcoin.com.br/news/)
-- [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
-Developer
-
-- [APIs](https://developers.celcoin.com.br/reference)
-- [Documentação](https://developers.celcoin.com.br/docs)
-- [Developers](https://www.celcoin.com.br/developers/)
-- [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-### Atendimento Celcoin
-
-De segunda a sexta-feira: das 09h às 18h
-
-## Telefone
-
-[0800 591 1457](tel:5070-8153)
-
-## Whatsapp
-
-[(11) 4765-5043](https://wa.me/551147655043)
-
-[Enviar uma solicitação](https://suporte.celcoin.com.br/hc/pt-br/requests/new)
-
-### Ouvidoria
-
-De segunda a sexta-feira: das 09h às 17h
-
-## Telefone
-
-[0800 591 1852](tel:08005911852)
-
-Celcoin Instituição de Pagamento S.A - 13.935.893/0001-09
-Al. Xingu, 350 – Conj 1604 – Alphaville Industrial Barueri – SP – 06455-030
-
-[
-
-Configuração de cookies
-
-
-
-](https://www.celcoin.com.br/compliance-e-regulatorio/)[
-
-Privacidade e termos
-
-
-
-](https://www.celcoin.com.br/compliance-e-regulatorio/)
-
- 
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://dock.tech/en/financial-services/banking/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Error:**
-```
-Request failed with status code: 404
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.celcoin.com.br/produtos/banking/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Image fetched successfully
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 20.5s)
-
-_Thinking:_
-
-**Comparing setups with partners**
-
-I need to help the user compare this setup with other potential partners like Dock and Celcoin. It seems the initial idea was to use their BaaS and maybe PaaS. I’m thinking it’s essential to analyze their documentation and see how our Z.ro setup matches up. While we're in plan mode and can only read, I might need to fetch developer docs for Dock and Celcoin, and maybe even use context7 to gather more insights.
-
-_Thinking:_
-
-**Comparing Z.ro with partners**
-
-I should search relevant pages, possibly using multi_tool_use.parallel to gather information. I think webfetch will be suitable for developer pages, while context7 can help with partner documentation. I need to compare our Z.ro BaaS and PaaS setup with Dock and Celcoin, looking at factors like BaaS quality, payment acceptance, compliance, and developer experience.
-
-It's worth noting that if we only use Z.ro's PaaS, customer payment acceptance might not be fully covered, unlike the broader offerings from Dock and Celcoin, who seem more proven in their infrastructure.
-
-_Thinking:_
-
-**Citing public metrics carefully**
-
-I need to be cautious about making unsupported claims and stick to what's in the documentation. For Dock, I can mention that they have around 70 million active accounts, are a direct Pix participant, and have 400+ customers with 1.3 billion Pix transactions in 12 months. For Celcoin, they have over 6,000 clients, R$30 billion monthly, and 400 million transactions monthly, also being a direct Pix participant. Z.ro has an A-level Central Bank ranking, a payment institution license, and has transacted 50 billion reals through 100 million transactions.
-
-Comparing the infrastructure layers now: developer surface, regulated rails, payment acceptance breadth, and whether each provider matches a BaaS-first launch without forcing us into a full neobank build.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://developers.dock.tech/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- ReadMe
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://developers.celcoin.com.br/docs",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-Uma breve introdução
-
-[Jump to Content](#content)
-
-[](/)
-
-[Documentação](/docs)[Recipes](/recipes)[API](/reference)[Ask AI](javascript:window.Kapa.open\(\))v2.0.0v2.0.1
-
----
-
-[Status Page](/page/status-page)[Suporte](https://suporte.celcoin.com.br/hc/pt-br/requests/new?ticket_form_id=4553742630939)[](/)
-
-Documentação
-
-Search
-
-[Status Page](/page/status-page)[Suporte](https://suporte.celcoin.com.br/hc/pt-br/requests/new?ticket_form_id=4553742630939)
-
-v2.0.0
-
-[Documentação](/docs)[Recipes](/recipes)[API](/reference)[Ask AI](javascript:window.Kapa.open\(\))
-
-Uma breve introdução
-
-All
-
-Pages
-
-###### Start typing to search…
-
-## Introdução
-
-- [Uma breve introdução](/docs/bem-vindo-à-api-da-rede-celcoin)
-- [Credenciais de acesso](/docs/obtendo-acesso-às-apis)
-- [Segurança da API](/docs/segurança-da-api)
- - [Idempotência das APIs](/docs/idempotência-das-apis)
- - [Certificado mTLS](/docs/mtls)
- - [Controle de taxa (rate-control)](/docs/controle-de-taxa-rate-control)
-- [Faça sua primeira consulta](/docs/tutorial-de-uso-da-api)
-- [Arquivo de movimentação via SFTP](/docs/arquivo-de-movimentação-via-sftp)
-- [Servidor MCP da Celcoin](/docs/use-nosso-mcp-server)
-
-## Homologação
-
-- [Instruções para homologar](/docs/homologacao-celcoin)
-
-## cel\_banking - BaaS & Core
-
-- [Sobre o BaaS & Core Banking](/docs/sobre-o-baas)
-- [Follow the Money (Antifraude e PLD)](/docs/follow-the-money-ftm)
-- [Abertura de Contas (KYC)](/docs/utilizacao-do-onboarding-celcoin)
- - [Criação de Contas (Onboarding)](/docs/utilizacao-do-onboarding-celcoin)
- - [Informações financeiras](/docs/informações-financeiras-1)
- - [Webhooks Onboarding](/docs/webhooks-onboarding)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/categories/26054953034011-Onboarding-KYC)
-- [Gestão de Contas](/docs/gestão-de-contas)
- - [Criar Conta - Apenas Core Banking](/docs/criar-conta)
- - [Informações financeiras](/docs/informações-financeiras)
- - [Atualizar Dados do Cliente](/docs/atualizar-dados-da-conta)
- - [Desativar / Encerrar uma Conta](/docs/desativar-excluir-a-conta)
- - [Listar Contas](/docs/listar-contas)
- - [Tabela de erros Gestão de Contas](/docs/tabela-de-erros-gestão-de-contas)
- - [Número de contas](/docs/numero-de-contas)
- - [Bloqueios Judiciais](/docs/bloqueio-judiciais)
- - [Atualização de Status de Conta](/docs/atualização-de-status-de-conta)
- - [Adicionar Saldo (em sandbox)](/docs/gerar-lançamento)
-- [Relatórios](/docs/relatórios-2)
- - [Consultar Saldo](/docs/consultar-saldo-1)
- - [Saldo Dia & Movimentações Diárias Consolidadas](/docs/consultar-saldo-do-dia)
- - [Consultar Extrato](/docs/consultar-extrato-1)
- - [Consultar Extrato Detalhado](/docs/consultar-extrato-copy)
- - [Consultar Transações do Extrato](/docs/consultar-transacoes-extrato)
-- [Pix](/docs/sobre-o-pix)
- - [Sobre o Pix](/docs/sobre-o-pix)
- - [Implantação](/docs/pix-implantação)
- - [Cash-in (Receber)](/docs/pix-cash-in-receber)
- - [Receber um Pix Cash-in por Agência e Conta](/docs/receber-um-pix-cash-in-agencia-e-conta)
- - [Receber um Pix Cash-in por Chave Aleatória](/docs/receber-um-pix-cash-in-por-chave-aleatoria)
- - [Receber um Pix Cash-in por Chaves Individualizadas](/docs/receber-um-pix-cash-in-por-chaves-individualizadas)
- - [Receber um Pix Cash-in por Cobrança estática](/docs/receber-um-pix-cash-in-por-cobranca-estatica)
- - [Receber um Pix Cash-in por QR Code dinâmico (immediate)](/docs/receber-um-pix-cash-in-por-qr-code-dinamico-immediate)
- - [Receber um Pix Cash-in por QR Code dinâmico(duedate)](/docs/receber-um-pix-cash-in-por-qr-code-dinamico-duedate)
- - [Bloqueio Cautelar - Recebimento Pix](/docs/bloqueio-cautelar-recebimento-pix)
- - [Consulta de recebimentos Pix](/docs/redirecionamento-consulta-de-recebimentos-pix)
- - [Devolver um Pix Cash-in](/docs/realizar-devolução-de-recebimento-pix)
- - [Modelo Webhook](/docs/webhook-cash-in)
- - [Split Pix](/docs/split-pix)
- - [Split de Pix Cash-in por QR Code dinâmico(duedate)](/docs/split-de-pix-cash-in-por-qr-code-dinâmicoduedate)
- - [Split de Pix Cash-in por QR Code dinâmico (immediate)](/docs/split-de-pix-cash-in-por-qr-code-dinâmico-immediate)
- - [Cash-out (Pagamento)](/docs/pix-cash-out-pagamento)
- - [DICT](/docs/dict-2)
- - [Consultar Chaves Pix Externa (DICT)](/docs/consultar-chaves-pix-externa-dict)
- - [Realizar um Pix Cash-Out por Agência e Conta](/docs/realizar-um-pix-cash-out)
- - [Realizar um Pix Cash-Out por Chaves Pix](/docs/realizar-um-pix-cash-out-por-chaves-pix)
- - [Realizar um Pix Cash-Out por QR Code Estático](/docs/realizar-um-pix-cash-out-por-qr-code-estático)
- - [Realizar um Pix Cash-Out por QR Code Dinâmico](/docs/realizar-um-pix-cash-out-por-qr-code-dinâmico)
- - [Consultar transferências, pagamentos e devoluções de Pix-Out](/docs/verifica-o-status-de-uma-transação-pix)
- - [Modelo Webhook](/docs/modelo-webhook-cash-out)
- - [Gerenciamento de Chaves](/docs/pix-gerenciamento-de-chaves)
- - [Cadastrar uma Chave Pix](/docs/cadastrar-uma-chave-pix)
- - [Excluir Chaves Pix de uma Conta](/docs/excluir-chaves-pix-de-uma-conta)
- - [Consultar Chaves Pix de uma Conta](/docs/consultar-chaves-pix-de-uma-conta-copy)
- - [Alteração de nome em uma chave Pix](/docs/alterar-chaves-pix)
- - [Portabilidade e Reivindicação de Chaves](/docs/portabilidade-reivindicacao-de-chaves-pix)
- - [Primeiros passos para Portabilidade e Reivindicação de Chaves Pix](/docs/primeiros-passos-para-portabilidade-e-reivindicação-de-chaves-pix)
- - [Solicitar Portabilidade de Chave Pix](/docs/solicitar-portabilidade-de-chave-pix)
- - [Responder Portabilidade de Chave Pix](/docs/responder-portabilidade-de-chave-pix)
- - [Consultar pedidos de Portabilidade ou Reivindicação](/docs/consultar-pedidos-de-portabilidade-ou-reinvindicacao)
- - [Tabela de erros portabilidade PIX](/docs/tabela-de-erros-portabilidade-pix)
-- [Pix Automático](/docs/pix-automático-baas)
- - [Jornada Pagadora](/docs/jornada-pagadora-baas)
- - [Autorização - Visão Geral](/docs/autorização-pagador-baas)
- - [Autorização - Jornada 1](/docs/autorização-jornada-1-baas)
- - [Autorização - Jornada 2](/docs/autorização-jornada-2-baas)
- - [Autorização - Jornada 3](/docs/autorização-jornada-3-baas)
- - [Autorização - Jornada 4](/docs/autorização-jornada-4-baas)
- - [Agendamento](/docs/agendamento-pagador-baas)
- - [Liquidação](/docs/liquidação-pagador-baas)
- - [Cancelamento do Consentimento](/docs/cancelamento-pagador-baas)
- - [Cancelamento de agendamento](/docs/cancelamento-do-consentimento-copy)
- - [Consultas - Visão Pagador](/docs/consultas-visão-pagador)
- - [Jornada Recebedora](/docs/jornada-recebedora)
- - [Autorização - Jornada 1](/docs/recebedora-jornada-1)
- - [Autorização - Jornada 2](/docs/recebedora-jornada-2-baas)
- - [Autorização - Jornada 3](/docs/recebedora-jornada-2-copy)
- - [Autorização - Jornada 4](/docs/recebedora-jornada-3-copy)
- - [Envio de Agendamento](/docs/recebedora-envio-de-agendamento)
- - [Liquidação](/docs/recebedora-envio-de-agendamento-copy)
- - [Retentativas de Recebimento](/docs/recebedora-retentativas-de-recebimento)
- - [Cancelamento de Agendamento](/docs/recebedora-cancelamento-de-agendamento-baas)
- - [Cancelamento de Recorrência](/docs/recebedora-cancelamento-de-pix-automático)
- - [Motivos de rejeição pelo participante pagador](/docs/motivos-de-rejeição-pelo-participante-pagador)
-- [Pix Inteligente - Sweeping Accounts](/docs/pix-inteligente-sweeping-accounts)
- - [Listar marcas do Diretório de Participantes](/docs/copy-of-listar-marcas-no-diretório-de-participantes-do-open-finance)
- - [Criar consentimento](/docs/copy-of-criar-consentimento)
- - [Callback do Consentimento](/docs/copy-of-callback-do-consentimento)
- - [Cancelamento de consentimento](/docs/copy-of-cancelamento-de-consentimento)
- - [Listar Consentimentos](/docs/copy-of-listar-consentimentos)
- - [Buscar informações de um consentimento](/docs/copy-of-buscar-informações-de-um-consentimento)
- - [Criar um Pix inteligente recorrente](/docs/copy-of-pix-inteligente)
-- [Pix Indireto](/docs/sobre-o-pix-indireto-baas)
- - [Sobre o Pix Indireto](/docs/sobre-o-pix-indireto-baas)
- - [Pré-requisitos do Participante](/docs/pré-requisitos-do-participante-baas)
- - [Fases do processo de adesão do Participante Indireto](/docs/fases-do-processo-de-adesão-do-participante-indireto-baas)
- - [DICT (Diretório de Identificadores de Contas Transacionais)](/docs/gestão-de-chaves-pix-baas)
- - [Gestão de Chaves Pix](/docs/gestão-de-chaves-pix-baas)
- - [Portabilidade e Reivindicação](/docs/portabilidade-e-reivindicação-baas)
- - [Infrações](/docs/infrações-baas)
- - [Mecanismo Especial de Devoluções (MED)](/docs/mecanismo-especial-de-devoluções-med-baas)
-- [Agendador de Transação Pix](/docs/agendador-de-transacoes)
- - [Agendar uma transação Pix](/docs/agendar-uma-transação-pix)
- - [Consultar Pix agendado](/docs/consultar-pix-agendado)
- - [Cancelar um Pix agendado](/docs/cancelar-pix-agendado)
- - [Consultar Lista de Transações agendadas](/docs/consultar-transacoes-agendadas)
-- [Emissão de Boletos](/docs/cobrancas-avulsas)
- - [Emitir Boleto/Cobrança](/docs/criar-uma-cobrança-avulsa)
- - [Emitir Boleto/Cobrança com Split de Pagamento](/docs/criar-uma-cobrança-avulsa-com-split)
- - [Criar um PDF para uma Cobrança](/docs/criar-um-pdf-para-uma-cobrança)
- - [Consultar Boleto Emitido](/docs/consultar-cobranca-avulsa)
- - [Consultar Boletos por Período](/docs/consultar-cobrança-periodo)
- - [Cancelar Boleto Emitido](/docs/cancelar-uma-cobrança-avulsa)
-- [CNAB](/docs/modulo-cnab-baas)
- - [Processar, Consultar e Baixar CNAB](/docs/processar-um-arquivo-cnab)
-- [Subadquirência e AaaS (Acquiring as a Service)](/docs/subadquirencia)
- - [Credenciamento na Subadquirência](/docs/credenciamento-sub-adquirência)
- - [Validação de Status da Conta](/docs/listar-conta)
- - [Cobrança avulsa no Cartão de Crédito](/docs/cobrança-avulsa-cartão-de-crédito)
- - [Criar Cobrança Avulsa](/docs/criar-cobrança-avulsa)
- - [Listar Cobranças Avulsas](/docs/listar-cobrança-avulsa)
- - [Editar Cobrança Avulsa](/docs/editar-cobrança-avulsa)
- - [Retentar Cobrança Avulsa](/docs/retentar-cobrança-avulsa)
- - [Estornar Cobrança Avulsa](/docs/estornar-cobrança-avulsa)
- - [Cancelar Cobrança Avulsa](/docs/cancelar-cobrança-avulsa)
- - [Disputas e Chargebacks](/docs/gestão-de-chargebacks)
- - [Listar Chargebacks](/docs/listar-chargebacks)
- - [Enviar Documentação de Defesa do Chargeback](/docs/enviar-documentação-de-defesa-do-chargeback)
- - [Desistir da Disputa dos Chargeback](/docs/desistir-da-disputa-dos-chargeback)
- - [Cadastrar Webhooks de Chargeback](/docs/cadastro-de-webhooks-de-chargeback)
- - [Clientes](/docs/clientes)
- - [Criar Cliente](/docs/criar-cliente)
- - [Listar Clientes](/docs/listar-clientes)
- - [Editar Cliente](/docs/editar-cliente)
- - [Excluir Cliente](/docs/excluir-cliente)
- - [Planos](/docs/planos)
- - [Criar Plano](/docs/criar-plano)
- - [Listar Planos](/docs/listar-planos)
- - [Editar Plano](/docs/editar-plano)
- - [Excluir Plano](/docs/excluir-plano)
- - [Cartões](/docs/cartões)
- - [Criar Cartão](/docs/criar-cartão)
- - [Listar Cartões](/docs/listar-cartões)
- - [Inativar Cartão](/docs/inativar-cartão)
- - [Assinaturas e Contratos](/docs/assinaturas-e-contratos)
- - [Criar Assinatura/Contrato Manual](/docs/criar-assinaturacontrato-manual)
- - [Adicionar Transação](/docs/adicionar-uma-transação)
- - [Webhooks](/docs/configurar-webhooks)
- - [Tokenização de Cartão via JS](/docs/tokenização-de-cartão-via-js)
-- [Pagamento de boletos](/docs/pagamento-de-boletos-tributos)
- - [Realizar um pagamento de boletos](/docs/realizar-um-pagamento-de-boletos)
- - [Consultar Status de uma pagamento de Boleto](/docs/consultar-status-de-pagamento-de-boleto)
-- [Transferência entre contas](/docs/transferencia-entre-contas)
- - [Transferência entre contas internas](/docs/transferência-entre-contas-baas)
- - [Consulta status da uma transferência entre contas](/docs/consultar-status-de-um-transferência-entre-contas-baas)
-- [TED](/docs/transferencia-ted)
- - [Recebendo Transferências TED na sua Conta BaaS](/docs/receber-uma-transferência-ted)
- - [Realizar uma Transferência via TED](/docs/realizar-uma-transferência-via-ted)
- - [Consultar status de um transferência TED](/docs/consultar-status-de-um-transferência-ted)
- - [Modelos Webhooks](/docs/webhooks-2)
-- [Débito Veicular](/docs/debito-veicular-baas)
- - [Consultar Débitos Veiculares](/docs/consultar-débitos-veiculares)
- - [Efetivar Pagamento de Débitos Veiculares](/docs/efetivar-pagamento-de-débitos-veiculares)
- - [Débitos Dependentes, Distintos e Obrigatórios](/docs/débitos-dependentes-distintos-e-obrigatórios-baas)
- - [Massa de Testes Débito Veicular](https://docs.google.com/spreadsheets/d/1y_vPJ6_yOIm6JRsXIz9On6HUBMKyFxrm/edit?usp=sharing&ouid=111561115532951179309&rtpof=true&sd=true)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/categories/26366884684571-D%C3%A9bito-Veicular)
-- [Recargas](/docs/recarga)
- - [Consulta de operadoras e valores](/docs/consulta-de-operadoras-e-valores)
- - [Realizar uma recarga](/docs/realizar-uma-recarga)
-- [SLC (domicílio de arranjo de cartões)](/docs/recebimento-de-cartoes-slc)
- - [Recebimento de liquidações do arranjo de cartões via SLC (Domicílio Bancário)](/docs/recebimento-de-cartoes-slc)
-- [Informe de Rendimentos](/docs/informe-de-rendimentos)
- - [Informe de Rendimentos PF](/docs/informe-de-rendimentos-pf)
- - [Informe de Rendimentos PJ](/docs/informe-de-rendimentos-pj)
-- [Iniciador de Transação de Pagamento (ITP)](/docs/open-keys-itp-copy)
- - [Portal de configurações do Open Keys](/docs/portal-de-configurações-do-open-keys-copy)
- - [Dashboard](/docs/dashboard-copy)
- - [Lista de Transações](/docs/lista-de-transações-copy)
- - [Relatório de Transações](/docs/relatório-de-transações)
- - [Configurações da jornada de pagamentos](/docs/configurações-da-jornada-de-pagamentos-copy)
- - [Demo das Jornadas de Pagamento](/docs/demo-das-jornadas-de-pagamento-copy)
- - [Demo da Área de Gestão](/docs/demo-da-área-de-gestão-copy)
- - [Jornadas White Label](/docs/jornadas-white-label-copy)
- - [Iniciação de Pagamento Instantâneo](/docs/iniciação-de-pagamento-instantâneo-copy)
- - [Gestão de Pagamentos Instantâneos](/docs/gestão-de-pagamentos-instantâneos-copy)
- - [Iniciação de Pagamento Agendado](/docs/iniciação-de-pagamento-agendado-copy)
- - [Gestão de Pagamentos Agendados](/docs/gestão-de-pagamentos-agendados-copy)
- - [Iniciação de Pagamento sem Redirecionamento](/docs/iniciação-de-pagamento-sem-redirecionamento-copy)
- - [Gestão de Contas Salvas (Vínculos)](/docs/gestão-de-contas-salvas-vínculos-copy)
- - [FAQ Open Keys](/docs/faq-open-keys-copy)
- - [Pix por Aproximação](/docs/pix-por-aproximação-copy)
- - [Jornada Pay by Link](/docs/jornada-pay-by-link-copy)
- - [Documentação técnica](/docs/documentação-técnica-copy)
- - [Status e respostas: Máquina de estados](/docs/status-e-respostas-máquina-de-estados-copy)
- - [Status e respostas: Códigos de resposta HTTP](/docs/status-e-respostas-códigos-de-resposta-http-copy)
- - [Status e respostas: Possíveis erros de pagamentos](/docs/status-e-respostas-possíveis-erros-de-pagamentos-copy)
- - [Diagrama de sequência: Jornada com Redirecionamento](/docs/diagrama-de-sequência-jornada-com-redirecionamento-copy)
- - [Diagrama de sequência: Jornada sem Redirecionamento](/docs/diagrama-de-sequência-jornada-sem-redirecionamento-copy)
- - [Webhook](/docs/webhook-copy)
- - [APIs](/docs/apis-copy)
- - [🚀 ITP – Jornada de Pagamento com Redirecionamento](/docs/itp-jornada-de-pagamento-com-redirecionamento)
-- [Open Finance as a Service](/docs/marcas-no-open-finance)
- - [Marcas no Open Finance](/docs/marcas-no-open-finance)
- - [Listar marcas no Diretório de Participantes do Open Finance](/docs/listar-marcas-no-open-finance)
- - [Obter detalhes de marcas no Open Finance](/docs/obter-detalhes-de-marcas-no-open-finance)
- - [Uso e disponibilização de logotipos](/docs/copy-of-instituições-no-open-finance)
- - [Termos e Condições de uso](/docs/copy-of-uso-e-disponibilização-de-logotipos)
- - [Recepção de Dados](/docs/copy-of-fluxo-de-utilização-da-api-de-dados-1)
-- [Webhooks](/docs/webhooks-baas)
- - [Cadastrar e Gerenciar Webhooks](/docs/gerenciamento-de-webhook)
- - [Reenvio de Webhook](/docs/reenvio-de-webhook)
- - [Templates de Webhooks do BaaS](/docs/templates-de-webhooks-do-baas)
- - [Bloqueio/desbloqueio de saldo por infração](/docs/bloqueiodesbloqueio-de-saldo-por-infração)
-- [Tabela de erros BaaS](/docs/tabela-de-erros-mapeados)
-
-## cel\_banking - cards
-
-- [Sobre cel\_card](/docs/cel_card)
- - [Comece a Emitir Cartões](/docs/comece-a-emitir-cartões)
-- [Gestão de Conta Cartão](/docs/onboarding)
- - [Criar uma Conta Cartão (Onboarding)](/docs/copy-of-criar-conta-cartão-onboarding)
- - [Atualizando Dados Cadastrais da Conta Cartão](/docs/onboarding-copy)
- - [Consultando dados de uma Conta Cartão](/docs/copy-of-consultando-dados-de-uma-conta-cartão)
- - [Limites da Conta Cartão](/docs/limites-da-conta-cartão)
- - [Cancelamento de conta e cartão](/docs/copy-of-bia-consultando-fatura-4)
-- [Endereços](/docs/endereço)
- - [Cria um novo endereço para uma conta](/docs/cria-um-novo-endereço-para-uma-conta)
- - [Alteração de endereço de entrega](/docs/alteração-de-endereço-de-entrega)
- - [Listar endereços de uma conta](/docs/listar-endereços-de-uma-conta)
-- [Emissão de Cartões](/docs/emissão-de-cartões)
- - [Emissão/Geração de Cartão](/docs/emissão-de-cartão-físico)
- - [Emissão de 2ª via de cartão](/docs/emissão-de-2a-via-de-cartão)
-- [Rastreio de Cartões](/docs/rastreio-de-cartões)
- - [Consulta de rastreio](/docs/consulta-de-rastreio)
- - [Simulação de Rastreio do Cartão](/docs/simulação-de-rastreio-do-cartão)
-- [Gestão de Cartões](/docs/gestão-de-cartão)
- - [Ativação](/docs/ativação)
- - [Listagem de Cartões](/docs/listagem-de-cartões)
- - [Configuração de contactless (NFC)](/docs/configuração-de-contactless)
- - [Gestão de senha](/docs/gestão-de-senha)
- - [Alteração de Senha do Cartão - Pin Online e Pin Offline](/docs/copy-of-pin-on-line-e-pin-off-line)
- - [Visualização dos dados do cartão](/docs/visualização-dos-dados-do-cartão)
- - [Simulador de Transações](/docs/simulador-de-transacao)
-- [Webhooks](/docs/webhooks-cartoes)
- - [Cadastrar e Gerenciar Webhooks](/docs/cadastrar-e-gerenciar-webhooks)
- - [Template de Webhooks](/docs/modelo-de-webhooks)
- - [Reenvio de Webhook Pendente](/docs/reenvio-de-webhook-1)
-- [Entendendo a Fatura](/docs/copy-of-bia-consultando-fatura-5)
- - [Consultando dados de fatura](/docs/bia-consultando-fatura)
-
-## cel\_credit
-
-- [Autenticação](/docs/autenticação)
-- [Produtos](/docs/produtos)
-- [Variáveis Personalizadas](/docs/variáveis-personalizadas)
-- [Pessoas](/docs/pessoas)
- - [Campos da Pessoa](/docs/campos-da-pessoa)
-- [Empresas](/docs/empresas)
- - [Campos Empresa](/docs/campos-empresa)
- - [Responsáveis Legais](/docs/responsáveis-legais)
-- [Documentos](/docs/documentos)
-- [Solicitações](/docs/solicitações)
- - [Campos de Solicitação](/docs/campos-de-solicitação)
- - [Simulações](/docs/simulações)
- - [Status de Solicitação](/docs/status-de-solicitacao)
- - [Tabela de Erros de Geração de Boleto](/docs/tabela-de-erros-de-geração-de-boleto)
- - [Assinatura](/docs/assinatura)
- - [Modalidades](/docs/modalidades)
- - [Clicksign](/docs/clicksign)
- - [UNICO](/docs/unico)
- - [ZapSign](/docs/zapsign)
-- [Webhooks](/docs/webhooks-1)
-- [Consignado Crédito Trabalhador](/docs/consignado-crédito-trabalhador)
- - [Modalidade com Leilão Interno](/docs/modalidade-com-leilão-interno)
- - [Solicitação de Proposta & Distribuição aos Originadores](/docs/solicitação-de-proposta-distribuição-aos-originadores)
- - [Oferta, Leilão, Devolutiva & Emissão](/docs/envio-da-oferta-leilão-interno-devolutiva)
- - [Modalidade sem Leilão](/docs/modalidade-sem-leilao)
- - [Solicitação & Consentimento do Tomador](/docs/solicitação-consentimento-do-tomador)
- - [Consulta de Margem & Simulação de Crédito](/docs/consulta-de-margem-simulação-de-crédito)
- - [Cadastro do Tomador, Emissão & Cancelamento](/docs/cadastro-do-tomador-emissão-cancelamento-1)
- - [Guia rápido consignado](/docs/guia-rápido-consignado)
- - [Falhas de Averbação – Integração Dataprev](/docs/erros-de-averbação-integração-dataprev)
- - [Status da Operação](/docs/status-da-operação)
- - [Consultas, Escriturações e Repasses](/docs/consultas-escriturações-e-repasses)
-- [Empréstimo Consignado Servidores do Exército](/docs/empréstimo-consignado-servidores-do-exército)
- - [Autenticação](/docs/autenticação-3)
- - [Consulta de margem](/docs/consulta-de-margem-2)
- - [Simulação da CCB](/docs/simulação-da-ccb-1)
- - [Criação do tomador](/docs/criação-do-tomador)
- - [Compra com troco](/docs/compra-com-troco)
- - [Status da Operação](/docs/status-da-operação-3)
-- [Conta escrow](/docs/conta-escrow)
- - [Onboarding conta escrow](/docs/onboarding-conta-escrow)
- - [Fluxo essencial](/docs/fluxo-essencial)
- - [Depósitos](/docs/depósitos)
- - [Destinatários e Cobranças (Charges)](/docs/destinatários-e-cobranças-charges)
- - [Permissões](/docs/permissões)
-- [Portabilidade de Crédito](/docs/portabilidade-de-crédito)
- - [Portabilide de Crédito do Trabalhador](/docs/portabilide-de-crédito-do-trabalhador)
- - [Portabilidade no ambiente do originador](/docs/portabilidade-no-ambiente-do-originador)
- - [Simulação de portabilidade de crédito do trabalhador](/docs/simulação-de-portabilidade-de-crédito-do-trabalhador-1)
- - [Autorização de consulta & consulta de vículo empregatício](/docs/autorização-de-consulta-consulta-de-vículo-empregatício)
- - [Cadastro do tomador & emissão da CCB de portabilidade](/docs/cadastro-do-tomador-emissão-da-ccb-de-portabilidade)
- - [Proposta de portabilidade e resposta a proposta](/docs/proposta-de-portabilidade-e-retorno-da-proposta)
- - [Averbação por portabilidade & envio de contrato](/docs/averbação-por-portabilidade)
-
-## cel\_banking - embedded solutions
-
-- [Conta Celcoin](/docs/conta-celcoin)
-- [DDA](/docs/sobre-dda)
- - [Sobre DDA](/docs/sobre-dda)
- - [Tabela de erros](/docs/tabela-de-erros-2)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/sections/26051983538971-D%C3%A9bito-Direto-Autorizado-DDA)
-- [Débitos Veiculares](/docs/sobre-a-api-de-auto)
- - [Sobre a API de Débito Veicular](/docs/sobre-a-api-de-auto)
- - [Enriquecimento de Placas](/docs/enriquecimento-de-placas-debito-veicular)
- - [Débitos Dependentes, Distintos e Obrigatórios](/docs/débitos-dependentes-distintos-e-obrigatórios)
- - [Cadastro de Webhook com Autenticação Via Token - JWT](/docs/cadastro-de-webhook-com-autenticação-via-token-jwt)
- - [Idempotencia](/docs/idempotencia)
- - [Tabela de erros](/docs/tabela-de-erros-3)
- - [Massa de Testes Débito Veicular](https://docs.google.com/spreadsheets/d/1y_vPJ6_yOIm6JRsXIz9On6HUBMKyFxrm/edit?usp=sharing&ouid=111561115532951179309&rtpof=true&sd=true)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/categories/26366884684571-D%C3%A9bito-Veicular)
-- [Emissão de Nota Fiscal de Serviço (NFs-e)](/docs/sobre-a-api-de-emissão-nfse)
- - [Sobre a API de Emissão de Nota Fiscal de Serviços (NFs-e)](/docs/sobre-a-api-de-emissão-nfse)
- - [Tabela de Erros](/docs/tabela-de-erros-nfse)
-- [Emissão de Boletos - Conta Única (Direto)](/docs/emissao-de-boletos)
- - [Gestão de Beneficiários](/docs/gestao-beneficiario-direto)
- - [Gestão de Carteiras](/docs/gestao-de-carteiras-direto)
- - [Gestão de Emissão de Boletos](/docs/gestao-de-emissao-boletos)
- - [Gestão de Baixa de Boletos](/docs/gestao-de-baixa-boletos)
- - [Tabelas de Erros - Emissão Celcoin](/docs/tabela-erros-emissao-de-boletos-celcoin)
-- [Pagamento de contas](/docs/pagamento-de-contas-1)
- - [Sobre as APIs de Pagamento de Contas](/docs/pagamento-de-contas-1)
- - [Devolução de pagamento de conta](/docs/devolução-de-pagamento-de-conta)
- - [Massa de dados para testes](/docs/massa-de-dados-para-teste)
- - [Tabelas de erros das APIs](/docs/tabelas-de-erros)
- - [Lista de Convênios](https://developers.celcoin.com.br/page/conv%C3%AAnios-pagamento-contas)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/categories/26051936372763-Pagamento-de-contas-e-DDA)
-- [Pix](/docs/pix-avulso)
- - [Pix - Avulso](/docs/pix-avulso)
-- [Recargas](/docs/sobre-recargas-nacionais)
- - [Sobre recargas nacionais](/docs/sobre-recargas-nacionais)
- - [Termos de uso](https://docs.google.com/spreadsheets/d/e/2PACX-1vR8XRItuBRRxO4ioui90L-NRLuRRORzFoFoHVDKZvwDeZDqeyx2OokgVJMzv3otlA/pubhtml)
- - [FAQs](https://suporte.celcoin.com.br/hc/pt-br/categories/26344423891867-Recargas)
-- [Saques e depósitos físicos](/docs/saques-e-depósitos)
- - [Sobre Saques e depósitos](/docs/saques-e-depósitos)
-- [TED](/docs/sobre-as-transferências)
- - [Sobre as transferências via TED](/docs/sobre-as-transferências)
- - [Tabela de erros ao realizar uma TED](/docs/tabela-de-erros)
-- [Conciliação](/docs/redirecionamento-api-para-conciliacao)
- - [APIs para Conciliação](/docs/redirecionamento-api-para-conciliacao)
-
-## CEL\_BRICKS WEBHOOKS
-
-- [Webhook Manager](/docs/celbricks-cadastrar-e-gerenciar-webhooks)
- - [Cadastrar e Gerenciar Webhooks](/docs/celbricks-cadastrar-e-gerenciar-webhooks)
- - [Reenvio de Webhook](/docs/celbricks-reenvio-de-webhook)
-
-## cel\_open
-
-- [Jornada Com redirecionamento](/docs/jornada-com-redirecionamento)
- - [Documentação Técnica - API](/docs/documentação-técnica-api)
- - [Criar Iniciação de Pagamento](/docs/criar-iniciação-de-pagamento-1)
- - [Callback da Iniciação de Pagamento](/docs/callback-da-iniciação-de-pagamento)
- - [PIX](/docs/pix-1)
- - [Documentação Técnica - WL](/docs/criar-jornada-de-pagamento-1)
- - [Criar Jornada de Pagamento](/docs/criar-jornada-de-pagamento-1)
- - [Listar Jornadas de Pagamento](/docs/listar-jornadas-de-pagamento-1)
- - [Buscar Jornada de Pagamento](/docs/buscar-jornada-de-pagamento-1)
-- [Jornada Sem Redirecionamento](/docs/jornada-sem-redirecionamento)
- - [Criar vínculo](/docs/criar-vínculo)
- - [Pagamento](/docs/pagamento)
- - [Documentação Técnica - API](/docs/documentação-técnica-1)
- - [Criar Vínculo](/docs/criar-vínculo-1)
- - [Callback do Vínculo](/docs/callback-do-vínculo)
- - [FIDO Registration Options](/docs/fido-registration-options)
- - [FIDO Registration](/docs/fido-registration)
- - [Criar Iniciação de Pagamento](/docs/criar-iniciação-de-pagamento)
- - [FIDO Sign Options](/docs/fido-sign-options)
- - [Autorização FIDO](/docs/autorização-fido)
- - [PIX](/docs/pix)
- - [Documentação Técnica - WL](/docs/criar-jornada-de-vínculo)
- - [Criar Jornada de Vínculo](/docs/criar-jornada-de-vínculo)
- - [Listar Jornadas de Vínculo](/docs/listar-jornadas-de-vínculo)
- - [Buscar Jornada de Vínculo](/docs/buscar-jornada-de-vínculo)
- - [Criar Jornada de Pagamento](/docs/criar-jornada-de-pagamento)
- - [Listar Jornadas de Pagamento](/docs/listar-jornadas-de-pagamento)
- - [Buscar Jornada de Pagamento](/docs/buscar-jornada-de-pagamento)
-- [Brick Bank](/docs/sobre-o-bricks)
- - [Receptora de Dados](https://developers.finansystech.com.br/docs/receptora-de-dados-do-brick-bank)
- - [Transmissora de Dados](https://developers.finansystech.com.br/docs/transmissora-de-dados-do-brick-bank)
- - [Detentora de Contas](https://developers.finansystech.com.br/docs/detentora-de-contas)
-- [Brick Insurance](/docs/brick-bank-copy)
- - [Receptora de Dados (Open Insurance)](https://developers.finansystech.com.br/docs/receptora-de-dados-do-brick-insurance)
- - [Transmissora de Dados (Open Insurance)](https://developers.finansystech.com.br/docs/transmissora-de-dados-do-brick-insurance)
-- [Open Plus](/docs/open-plus)
- - [Portal](/docs/portal)
- - [Cadastro e acesso](/docs/cadastro-e-acesso)
- - [Hall Open Plus](/docs/hall-open-plus)
- - [Gestão de aplicações](/docs/gestão-de-aplicações)
- - [Catálogo de produtos](/docs/catálogo-de-produtos)
- - [Gestão de membros da equipe](/docs/gestão-de-membros-da-equipe)
- - [Menu de usuário](/docs/menu-de-usuário)
- - [Painel de gestão da aplicação](/docs/painel-de-gestão-da-aplicação)
- - [Painel de gestão do produto](/docs/painel-de-gestão-do-produto)
- - [Documentação de produto](/docs/documentação-de-produto)
- - [Credenciais e usuário de teste](/docs/credenciais-e-usuário-de-teste)
- - [Subir em produção](/docs/subir-em-produção)
- - [Portal Configurações](/docs/portal-configurações)
-- [Plataforma de Iniciação (ITP)](/docs/solução-de-pagamentos-itp)
- - [Portal de configurações do Open Keys](/docs/portal-de-configurações-do-open-keys)
- - [Dashboard](/docs/dashboard)
- - [Lista de Transações](/docs/lista-de-transações)
- - [Lista de Vínculos de Conta](/docs/lista-de-vínculos-conta)
- - [Relatórios](/docs/relatórios-4)
- - [Configurações da jornada de pagamentos](/docs/configurações-da-jornada-de-pagamentos)
- - [Demo das Jornadas de Pagamento](/docs/demo-das-jornadas-de-pagamento)
- - [Demo da Área de Gestão](/docs/demo-da-área-de-gestão)
- - [Jornadas White Label](/docs/jornadas-white-label)
- - [Iniciação de Pagamento Instantâneo](/docs/iniciação-de-pagamento-instantâneo)
- - [Gestão de Pagamentos Instantâneos](/docs/gestão-de-pagamentos-instantâneos)
- - [Iniciação de Pagamento Agendado](/docs/iniciação-de-pagamento-agendado)
- - [Gestão de Pagamentos Agendados](/docs/gestão-de-pagamentos-agendados)
- - [Iniciação de Pagamento sem Redirecionamento](/docs/iniciação-de-pagamento-sem-redirecionamento)
- - [Gestão de Contas Salvas (Vínculos)](/docs/gestão-de-contas-salvas-vínculos)
- - [Iniciação de Pagamento Automático](/docs/iniciação-de-pagamento-automático)
- - [Gestão de Pagamentos Automáticos](/docs/gestão-de-pagamentos-automáticos)
- - [FAQ Open Keys](/docs/faq-open-keys)
- - [Jornada Pay by Link](/docs/perguntas-frequentes)
- - [Pix por Aproximação](/docs/pix-por-aproximacao)
- - [Documentação técnica](/docs/documentação-técnica)
- - [Status e respostas: Máquina de estados](/docs/status-e-respostas-máquina-de-estados)
- - [Status e respostas: Códigos de resposta HTTP](/docs/status-e-respostas-códigos-de-resposta-http)
- - [Status e respostas: Possíveis erros de pagamentos](/docs/status-e-respostas-possíveis-erros-de-pagamentos)
- - [Diagrama de sequência: Jornada com Redirecionamento](/docs/diagrama-de-sequência-jornada-com-redirecionamento)
- - [Diagrama de sequência: Jornada sem Redirecionamento](/docs/diagrama-de-sequência-jornada-sem-redirecionamento)
- - [Webhook](/docs/webhook-itp)
- - [APIs](/docs/apis-itp)
- - [Massa de Testes](/docs/massa-de-testes)
- - [Validar SUCESSO no valor máximo dentro do permitido no vínculo do pix](/docs/jsr-lim-001)
- - [Validar SUCESSO no valor máximo dentro do permitido no vínculo do pix e no limite diário](/docs/jsr-lim-001-1)
- - [Validar FALHA no valor que excede o limite](/docs/jsr-lim-002)
- - [Validar FALHA por saldo insuficiente](/docs/jsr-sal-003)
- - [Validar qual erro prevalece quando ambas as condições, valor limite excedido e saldo insuficiente, falham](/docs/jsr-mix-004)
- - [Validar FALHA por exceder o limite diário configurado pelo cliente](/docs/jsr-limd-005)
- - [Validar FALHA por exceder o limite noturno](/docs/jsr-limn-006)
- - [Validar FALHA quando o consentimento (autorização do cliente) está EXPIRADO](/docs/jsr-cons-007)
- - [Validar FALHA quando o consentimento é REVOGADO pelo cliente na Instituição Detentora](/docs/jsr-cons-008)
- - [Validar FALHA se o vínculo for REJEITADO por tempo limite de espera](/docs/jsr-fido-011)
- - [Transferências inteligentes (Sweeping Accounts)](/docs/sweeping-accounts)
- - [Criar consentimento](/docs/sweeping-accounts-criar-consentimento)
- - [Callback do Consentimento](/docs/sweeping-accounts-callback-do-consentimento)
- - [Cancelamento de consentimento](/docs/sweeping-accounts-cancelamento-de-consentimento)
- - [Listar Consentimentos](/docs/sweeping-accounts-listar-consentimentos)
- - [Buscar informações de um consentimento](/docs/sweeping-accounts-buscar-informações-de-um-consentimento)
- - [Criação de uma sessão de jornada](/docs/sweeping-accounts-criação-de-uma-sessão-de-jornada)
- - [Listar sessões de jornada](/docs/sweeping-accounts-listar-sessões-de-jornada)
- - [Buscar informações de uma sessão de jornada](/docs/sweeping-accounts-buscar-informações-de-sessao-de-jornada)
- - [Pix inteligente](/docs/pix-inteligente)
-
-## Pix Indireto
-
-- [Sobre o Pix Indireto](/docs/sobre-o-pix-indireto)
- - [Introdução](/docs/pré-requisitos-do-participante)
- - [Pré-requisitos do Participante](/docs/pré-requisitos-do-participante)
- - [Fases do processo de adesão do Participante Indireto](/docs/fases-do-processo-de-adesão-do-participante-indireto)
-- [DICT (Diretório de Identificadores de Contas Transacionais)](/docs/gestão-de-chaves-pix)
- - [Gestão de Chaves Pix](/docs/gestão-de-chaves-pix)
- - [Listar todas as chaves pix de um cliente](/docs/listar-chaves-pix-de-um-cliente)
- - [Portabilidade e Reivindicação](/docs/portabilidade-e-reivindicação-1)
-- [Infrações e MED](/docs/infrações)
- - [Infrações](/docs/infrações)
- - [Mecanismo Especial de Devoluções (MED)](/docs/mecanismo-especial-de-devoluções-med)
- - [Marcação de fraude](/docs/marcação-de-fraude)
-- [MED 2.0](/docs/med-20)
- - [Criação recuperação de valores](/docs/criar-recuperação-de-valores)
- - [Consulta recuperação de valores](/docs/consulta-recuperação-de-valores)
- - [Cancela recuperação de valores](/docs/cancela-recuperação-de-valores)
- - [Cria solicitação de devolução em recuperação de valores](/docs/cria-solicitação-de-devolução-em-recuperação-de-valores)
- - [Consulta grafo de recuperação de valores](/docs/consulta-grafo-de-recuperação-de-valores)
- - [Atualizar a recuperação de valores](/docs/atualizar-a-recuperação-de-valores)
- - [Status da Recuperação de Valores](/docs/webhook-de-status-da-recuperação-de-valores)
- - [Fechar uma Recuperação de valores](/docs/fechar-uma-recuperação-de-valores)
- - [Fechar devolução em recuperação de valores](/docs/fechar-devolução-em-recuperação-de-valores)
-- [Autorização do CashIn](/docs/autorização)
- - [Autorização](/docs/autorização)
-- [QR Code](/docs/acesso-às-apis-de-integração)
- - [Receber com Pix (Pix Cash-in Indireto)](/docs/acesso-às-apis-de-integração)
-- [Transferências](/docs/transferências-e-pagamentos-com-pix-pix-cash-out-para-indiretos)
- - [Pagamentos (Pix cash-out para Indiretos)](/docs/transferências-e-pagamentos-com-pix-pix-cash-out-para-indiretos)
- - [Recebimentos (Pix Cashin)](/docs/recebimentos-pix-cashin)
- - [Devolução de recebimentos Pix](/docs/devolução-de-recebimentos-pix-copy)
- - [Transações fora do SPI - Reporte Bacen](/docs/transações-fora-do-spi-reporte-bacen)
- - [Pix Saque/Troco](/docs/pix-saquetroco)
-- [Tabela de erros para participantes Indiretos do Pix](/docs/tabela-de-erros-pix-indireto)
-- [Pix Automático](/docs/pix-automático-copy-1)
- - [Jornada Pagadora](/docs/jornada-pagadora-copy)
- - [Autorização - Visão Geral](/docs/autorização-visão-geral-copy)
- - [Autorização - Jornada 1](/docs/autorização-jornada-1-copy-3)
- - [Autorização - Jornada 2](/docs/autorização-jornada-2-copy-3)
- - [Autorização - Jornada 3](/docs/autorização-jornada-3-copy-3)
- - [Autorização - Jornada 4](/docs/autorização-jornada-4-copy-3)
- - [Agendamento](/docs/agendamento-copy-1)
- - [Liquidação](/docs/liquidação-copy-3)
- - [Cancelamento do Consentimento](/docs/cancelamento-do-consentimento-copy-2)
- - [Cancelamento de agendamento](/docs/cancelamento-de-agendamento-copy-3)
- - [Consultas - Visão Pagador](/docs/consultas-visão-pagador-copy-1)
- - [Jornada Recebedora](/docs/jornada-recebedora-copy)
- - [Autorização - Jornada 1](/docs/autorização-jornada-1-copy-2)
- - [Autorização - Jornada 2](/docs/autorização-jornada-2-copy-2)
- - [Autorização - Jornada 3](/docs/autorização-jornada-3-copy-2)
- - [Autorização - Jornada 4](/docs/autorização-jornada-4-copy-2)
- - [Envio de Agendamento](/docs/envio-de-agendamento-copy-1)
- - [Liquidação](/docs/liquidação-copy-2)
- - [Retentativas de Recebimento](/docs/retentativas-de-recebimento-copy-1)
- - [Cancelamento de Agendamento](/docs/cancelamento-de-agendamento-copy-2)
- - [Cancelamento de Recorrência](/docs/cancelamento-de-recorrência-copy-1)
-- [Webhooks](/docs/modelos-de-webhooks-do-pix-indireto)
- - [Modelos de webhooks do Participante Indireto Pix](/docs/modelos-de-webhooks-do-pix-indireto)
-
-## Pix - Avulso
-
-- [Sobre o Pix](/docs/sobre-pix)
-- [Receber com Pix (cash-in)](/docs/criar-cobrancas-com-pix-cashin)
- - [Cobrança imediata com QR Code dinâmico (immediate)](/docs/cobranca-imediata-com-qrcode-dinamico)
- - [Cobrança com vencimento com QR Code dinâmico (duedate)](/docs/qrcode-de-cobranca-com-vencimento)
- - [Cobrança estática](/docs/cobranca-com-qrcode-estatico)
- - [Consulta de recebimentos Pix](/docs/consultar-recebimentos-pix)
- - [Devolução de recebimentos Pix](/docs/devolução-de-um-recebimento-pix)
-- [Transferências e pagamentos com Pix (cash-out)](/docs/pagar-e-transferir-com-pix-cashout)
- - [DICT](/docs/dict-1)
- - [Balde de Fichas](/docs/balde-de-fichas)
- - [Transferência Pix a partir de dados bancários](/docs/transferencia-pix-com-dados-bancarios)
- - [Transferência Pix a partir de uma chave](/docs/transferencia-para-uma-chave-pix)
- - [Pagamento de um QR Code Estático](/docs/pagamento-de-um-qrcode-estatico)
- - [Pagamento de um QR Code Dinâmico](/docs/pagamento-de-um-qrcode-dinamico)
- - [Pix entre contas (Pix Interno)](/docs/pagamento-de-um-qr-code-dinâmico-copy)
- - [Consultar transferências, pagamentos e devoluções de Pix-Out](/docs/consultar-status-de-um-pagamento-pix)
- - [Pagamento de um QR Code (estático ou dinâmico)](/docs/pagamento-de-um-qr-code-estatico-ou-dinamico)
-- [Pix Automático](/docs/pix-automático-copy-copy)
- - [Jornada Pagadora](/docs/jornada-pagadora-copy-copy)
- - [Autorização - Visão Geral](/docs/autorização-visão-geral-copy-copy)
- - [Autorização - Jornada 1](/docs/autorização-jornada-1-copy-5)
- - [Autorização - Jornada 2](/docs/autorização-jornada-2-copy-5)
- - [Autorização - Jornada 3](/docs/autorização-jornada-3-copy-5)
- - [Autorização - Jornada 4](/docs/autorização-jornada-4-copy-5)
- - [Agendamento](/docs/agendamento-copy-2)
- - [Liquidação](/docs/liquidação-copy-5)
- - [Cancelamento do Consentimento](/docs/cancelamento-do-consentimento-copy-3)
- - [Cancelamento de agendamento](/docs/cancelamento-de-agendamento-copy-5)
- - [Consultas - Visão Pagador](/docs/consultas-visão-pagador-copy-2)
- - [Jornada Recebedora](/docs/jornada-recebedora-copy-copy)
- - [Autorização - Jornada 1](/docs/autorização-jornada-1-copy-4)
- - [Autorização - Jornada 2](/docs/autorização-jornada-2-copy-4)
- - [Autorização - Jornada 3](/docs/autorização-jornada-3-copy-4)
- - [Autorização - Jornada 4](/docs/autorização-jornada-4-copy-4)
- - [Envio de Agendamento](/docs/envio-de-agendamento-copy-2)
- - [Liquidação](/docs/liquidação-copy-4)
- - [Retentativas de Recebimento](/docs/retentativas-de-recebimento-copy-2)
- - [Cancelamento de Agendamento](/docs/cancelamento-de-agendamento-copy-4)
- - [Cancelamento de Recorrência](/docs/cancelamento-de-recorrência-copy-2)
-- [Tabela de erros Pix](/docs/tabela-de-erros-pix)
-- [FAQs](https://suporte.celcoin.com.br/hc/pt-br/sections/11326535846427-Pix)
-- [Webhook](/docs/modelos-de-webhooks-do-pix)
- - [Modelos de webhooks do Pix](/docs/modelos-de-webhooks-do-pix)
-
-## Conciliação
-
-- [API para Conciliação](/docs/sobre-api-de-conciliação)
- - [Sobre API de Conciliação](/docs/sobre-api-de-conciliação)
-- [API para Extrato Consolidado](/docs/sobre-api-de-extrato-consolidado)
- - [Sobre API de Extrato Consolidado](/docs/sobre-api-de-extrato-consolidado)
-- [Tabela de Erros](/docs/tabela-de-erros-conciliacao)
-
-## Suporte
-
-- [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
-- [SLA de atendimento](/docs/sla-de-atendimento)
-
-## PAINEL DO CLIENTE
-
-- [Listagem de Tickets](/docs/listagem-de-tickets)
-
-Powered by [](https://readme.com?ref_src=hub&project=celcoin)
-
-1. Introdução
-
-# Uma breve introdução
-
-**Seja bem-vindo(a)!**
-
-Aqui você encontrará tudo que precisa para ter sua melhor integração possível com as nossas APIs. Venha conosco e conduza seu negócio ao próximo nível! 🚀
-
-> 👍
->
-> ###
->
-> Procurando por alguma informação específica?
->
-> [](#procurando-por-alguma-informação-específica)
->
-> Temos uma função de pesquisa muito prática. Basta pressionar Command+K (MacOS) ou Ctrl+K (Windows) e digitar o que você está procurando!
-
-##
-
-O que é a Celcoin?
-
-[](#o-que-é-a-celcoin)
-
-A Celcoin, fundada em 2016, é uma infratech financeira para potencializar negócios.
-
-Através do cel\_bricks, sua solução Embedded Finance, ela fornece infraestrutura de tecnologia completa para empresas reguladas e não reguladas, dos mais diversos segmentos de atuação, e disponibiliza soluções modulares para banking, crédito, Open Finance, cash management, retail, onboarding e emissão de cartão.
-
-Pioneira no mercado, a Celcoin é também a vanguarda de mais uma transformação no segmento com o mybenk: solução de banking completa para todos os stakeholders de um ecossistema. Um bank com e de Endofinance!
-
-Estão conectadas à plataforma da Celcoin cerca de 600 bancos digitais, unicórnios e fintechs, mais de 6 mil médias e grandes empresas e 40 mil pontos de varejo, que, juntos, processam mensalmente mais de R$ 40 bilhões.
-
-Seu reconhecimento também está em conquistas como prêmios de “Melhor Startup do Brasil” pela Seedstars, “Melhor Fintech do País” pelo BBVA Open Talent, “The Inclusive Fintech 50”, “100 Startups to Watch” pela Pequenas Empresas & Grandes Negócios, aporte financeiro da Summit Partners com participação da Innova Capital, assim como certificados “Great Place to Work (GPTW)” e “Empresa B”. Foi ainda uma das grandes vencedoras do “Prêmio Banking Transformation”, organizado pela Cantarino Brasileiro, na categoria Open Banking.
-
-Para fortalecer sua equipe e seu escopo de atuação, também realizou as aquisições das empresas Galax Pay, focada em soluções de cobrança recorrente, Flow Finance, que fornece infraestrutura de crédito, Finansystech, startup líder em soluções de Open Finance, e Regulatório+, de soluções regulatórias.
-
-Seja qual for o seu segmento de atuação, é simples oferecer serviços financeiros e bancários aos seus clientes. Isso é Celcoin. The best service for growth.
-
-##
-
-Plataforma multicanal
-
-[](#plataforma-multicanal)
-
-Nossos clientes utilizam nossas soluções para ofertarem diversos serviços envolvendo transações financeiras, acessarem dados via Open Banking e se conectarem a uma rede com milhares de pontos físicos. Assim, construímos uma conexão única entre a Celcoin, nossos clientes e milhões de clientes finais espalhados por todo o Brasil, que usufruem de experiências inovadoras.
-
-
-
-
-##
-
-Reconhecimento do mercado
-
-[](#reconhecimento-do-mercado)
-
-Nossas propostas e atuações são reconhecidas com alguns dos prêmios mais expressivos no cenário corporativo, conquistando também o apoio de grandes empresas em nossa jornada pela democratização dos serviços financeiros.
-
-
-
-Updated about 1 month ago
-
----
-
-What’s Next
-
-- [Obtenha suas credenciais de acesso](/docs/obtendo-acesso-às-apis)
-
-Ask AI
-
-
-
-© 2026 Celcoin - Todos os direitos reservados
-
-Celcoin.com.br
-
-
-
-SOLUÇÕES
-
-Auto
-
-[
-
-Débito Veicular
-
-](https://www.celcoin.com.br/solucoes/auto/debito-veicular/)
-
-Cobrança
-
-[
-
-Cobrança com Pix
-
-](https://www.celcoin.com.br/solucoes/cobranca/cobranca-com-pix/)[
-
-Cobrança Recorrente
-
-](https://www.celcoin.com.br/solucoes/cobranca/cobranca-recorrente/)
-
-[Crédito](https://www.celcoin.com.br/solucoes/credit-platform/)
-
-Pagamento de contas
-
-[
-
-Boletos e concessionárias
-
-](https://www.celcoin.com.br/solucoes/pagamento-de-contas/boletos-e-concessionarias/)
-
-Saques e Depósitos
-
-[
-
-Pix Saque e Pix Troco
-
-](https://www.celcoin.com.br/solucoes/saques-e-depositos/pix-saque-e-pix-troco/)[
-
-Rede Banco24Horas
-
-](https://www.celcoin.com.br/solucoes/saques-e-depositos/rede-banco24horas/)
-
-[Banking as a Service](https://www.celcoin.com.br/solucoes/banking-as-a-service/)
-
-[Corban as a Service](https://www.celcoin.com.br/solucoes/corban-as-a-service/)
-
-Open Banking
-
-[
-
-Compartilhamento de Dados
-
-](https://www.celcoin.com.br/solucoes/open-banking/compartilhamento-de-dados/)[
-
-Iniciação de pagamentos
-
-](https://www.celcoin.com.br/solucoes/open-banking/iniciacao-de-pagamentos/)
-
-Recargas
-
-[
-
-Gift Cards
-
-](https://www.celcoin.com.br/solucoes/recargas/gift-cards/)[
-
-Recarga de celular
-
-](https://www.celcoin.com.br/solucoes/recargas/recarga-de-celular/)[
-
-Recarga de streaming e TV pré-pago
-
-](https://www.celcoin.com.br/solucoes/recargas/streaming-e-tv-pre-pago/)[
-
-Recarga para 150 países
-
-](https://www.celcoin.com.br/solucoes/recargas/recarga-para-150-paises/)
-
-Transferências
-
-[
-
-Pix Cash-out
-
-](https://www.celcoin.com.br/solucoes/transferencias/pix-cash-out/)
-
-EMPRESA
-
-[Sobre Nós](https://www.celcoin.com.br/sobre-a-celcoin/) [News](https://news.celcoin.com.br/) [Trabalhe Conosco](https://jobs.kenoby.com/celcoin) [Demonstrações Financeiras](https://www.celcoin.com.br/demonstracoes-financeiras/)
-
-DEVELOPER
-
-[Por onde começar](https://developers.celcoin.com.br/docs) [Referências](https://developers.celcoin.com.br/reference/integrando-na-celcoin) [Suporte](https://suporte.celcoin.com.br/hc/pt-br/requests/new?ticket_form_id=4553742630939) [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-RECURSOS
-
-[Suporte](https://suporte.celcoin.com.br/hc/pt-br/requests/new?ticket_form_id=4553742630939) [Contato](https://www.celcoin.com.br/contato-celcoin/) [Ouvidoria](https://www.celcoin.com.br/ouvidoria/)
-
-POLÍTICAS & COMPLIANCE
-
-[
-
-Política de Gerenciamento de Riscos
-
-](https://www.celcoin.com.br/politica-de-gerenciamento-de-riscos-operacionais-e-liquidez/)[
-
-Política de Prevenção à Lavagem
-
-](https://www.celcoin.com.br/politica-de-prevencao-a-lavagem-de-dinheiro-e-ao-financiamento-do-terrorismo-pld-ft/)[
-
-Política de Segurança da Informação
-
-](https://www.celcoin.com.br/politica-de-seguranca-da-informacao-e-seguranca-cibernetica/)[
-
-Canal de Denúncia
-
-](https://www.contatoseguro.com.br/)
-
-[CASO DE USO](https://www.celcoin.com.br/casos-de-uso/)
-
-Celcoin Instituição de Pagamento S.A – 13.935.893/0001-09
-Al. Xingu, 350 – Conj 1604 – Alphaville Industrial Barueri – SP – 06455-030
-
-[
-
-Configurações de cookies
-
-](https://www.celcoin.com.br/politica-de-cookies/)[
-
-Privacidade e termos
-
-](https://www.celcoin.com.br/privacidade-e-termos/)[](https://www.linkedin.com/company/celcoin-financial-hub/)
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.celcoin.com.br/cel_payments/pix/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
-
-
- cel\_payments – Pix | Celcoin
-
-[](https://www.celcoin.com.br)
-
-- Soluções
-
- Close Soluções Open Soluções
-
- cel\_bricks Plataformas mybenk Open Finance
-
- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-
- Saiba mais como o Embedded Finance da Celcoin pode apoiar o seu negócio.
-
- 
-
- - [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-
- - [BaaS](https://www.celcoin.com.br/cel_banking/banking-as-a-service/)
- - [Banco Liquidante](https://www.celcoin.com.br/cel_banking/banco-liquidante/)
- - [Cartão White Label](https://www.celcoin.com.br/cel_banking/cartao-white-label/)
- - [Compartilhamento de Dados](https://www.celcoin.com.br/cel_banking/compartilhamento-de-dados/)
- - [Core Banking](https://www.celcoin.com.br/cel_banking/core-banking/)
- - [Open Insurance](https://www.celcoin.com.br/cel_banking/open-finance-insurance/)
- - [Regulatório](https://www.celcoin.com.br/cel_banking/regulatorio/)
-
- - [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-
- - [Débito Veicular](https://www.celcoin.com.br/cel_payments/debito-veicular/)
- - [Débito Veicular White Label](https://www.celcoin.com.br/cel_payments/debito-veicular-white-label/)
- - [Gateway de Pagamento](https://www.celcoin.com.br/cel_payments/gateway-de-pagamento/)
- - [ITP](https://www.celcoin.com.br/cel_payments/open-finance-itp/)
- - [Pagamento de contas](https://www.celcoin.com.br/cel_payments/pagamento-de-contas/)
- - [Pix](https://www.celcoin.com.br/cel_payments/pix/)
- - [Recargas](https://www.celcoin.com.br/cel_payments/recargas/)
- - [Saque e Depósito](https://www.celcoin.com.br/cel_payments/saque-e-deposito/)
-
- - [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-
- - [CCB](https://www.celcoin.com.br/cel_credit/ccb/)
- - [Consignado as a Service](https://www.celcoin.com.br/cel_credit/consignado-as-a-service/)
- - [Conta Escrow](https://www.celcoin.com.br/cel_credit/conta-escrow/)
- - [Core Credit](https://www.celcoin.com.br/cel_credit/core-credit/)
- - [Gestão de Carteira e Cobrança](https://www.celcoin.com.br/cel_credit/gestao-de-carteira-e-cobranca/)
- - [Nota Comercial](https://www.celcoin.com.br/cel_credit/nota-comercial/)
-
- [Plataforma de Antecipações](https://www.celcoin.com.br/plataforma-de-antecipacoes/)
-
- Uma plataforma moderna para antecipação de recebíveis com toda a infraestrutura regulatória, tecnológica e operacional da Celcoin.
-
- [Ver solução](https://www.celcoin.com.br/plataforma-de-antecipacoes/)
-
- 
-
- [mybenk](https://www.celcoin.com.br/mybenk/)
-
- Saiba mais como o mybenk pode apoiar a transformar o universo financeiro interno. Uma solução completa para todos seus stakeholders.
-
- [Ver solução](https://www.celcoin.com.br/mybenk/)
-
- 
-
- [Open Finance](https://www.celcoin.com.br/open-finance/)
-
- Todas as oportunidades do Open Finance para o seu negócio.
-
- 
-
- - [ITP](https://www.celcoin.com.br/cel_payments/open-finance-itp/)
- - [Pix Automático](https://www.celcoin.com.br/open-finance/pix-automatico/)
- - [Pix Inteligente](https://www.celcoin.com.br/open-finance/pix-inteligente/)
-
- - [Pix por Aproximação](https://www.celcoin.com.br/open-finance/pix-por-aproximacao/)
- - [Pix Biometria](https://www.celcoin.com.br/open-finance/pix-biometria/)
- - [Pix Recorrente](https://www.celcoin.com.br/open-finance/pix-recorrente/)
-
- - [Financial Data](https://www.celcoin.com.br/open-finance/financial-data/)
- - [Cadastro Expresso](https://www.celcoin.com.br/open-finance/cadastro-expresso/)
- - [Detentora de Conta](https://www.celcoin.com.br/open-finance/detentora-de-conta/)
-
-- Desenvolvedores
-
- Close Desenvolvedores Open Desenvolvedores
-
- Comece a integrar as soluções da Celcoin
-
- [Explorar soluções](https://www.celcoin.com.br/developers/)
-
- 
-
- Developer
-
- - [APIs](https://developers.celcoin.com.br/reference)
- - [Documentação](https://developers.celcoin.com.br/docs)
- - [Developers](https://www.celcoin.com.br/developers/)
- - [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-- Empresa
-
- Close Empresa Open Empresa
-
- Empresa
-
- - [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
- - [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
- - [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
- - [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
- [](https://www.celcoin.com.br/partners/)
-
-- Conteúdos
-
- Close Conteúdos Open Conteúdos
-
- CONTEÚDOS
-
- - [Eventos](https://www.celcoin.com.br/eventos/)
- - [Insights](https://www.celcoin.com.br/insights/)
- - [News](https://www.celcoin.com.br/news/)
- - [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
- Últimas novidades
-
- [ETFs: como funcionam e o que avaliar antes de investir](https://www.celcoin.com.br/news/investimento-em-etf/)
-
- 20 de March de 2026
-
- [Celcoin conquista certificação PCI DSS e reforça segurança como diferencial competitivo no mercado financeiro](https://www.celcoin.com.br/news/celcoin-recebe-certificacao-de-seguranca-pci-dss/)
-
- 19 de March de 2026
-
- [Mais de 60% dos consumidores abandonam suas compras após uma experiência negativa](https://www.celcoin.com.br/news/novo-comportamento-do-consumidor-no-varejo/)
-
- 19 de March de 2026
-
-
-[Entrar](#Login)
-
-Qual o seu painel na **Celcoin?**
-
-Cada painel tem sua credencial distinta.
-
-Não tem acesso? **Fale com um especialista**
-
-- cel\_bricks
-
-Acesse o Painel do Cliente para obter relatórios e simplificar a gestão financeira da sua empresa.
-
-- cel\_credit (escrow)
-
-Gerencie sua conta escrow com eficiência e praticidade.
-
-- Gateway de Pagamentos
-
-Gerencie suas finanças com eficiência e praticidade.
-
-Ainda não possui uma conta? **Cadastre-se**
-
-Qual o seu painel na **Celcoin?**
-
-Cada painel tem sua credencial distinta.
-
-- cel\_bricks
-
-- cel\_credit (escrow)
-
-- Gateway de Pagamento
-
-Não tem acesso?
-
-- Criar conta Celcoin (contratar)
-
-- Criar conta Gateway de Pagamento
-
-[Contratar](https://www.celcoin.com.br/contato-celcoin/)
-
-- [Celcoin](https://www.celcoin.com.br/)
-- [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-- Pix
-
-# Ofereça transferências e pagamentos instantâneos com o Pix
-
-Conte com a expertise da infratech que processa mais de 250 milhões de transações de Pix por mês. A Celcoin possui a tecnologia mais robusta e escalável do mercado, com nota A na ANS (Acordo de Níveis de Serviço) do BC.
-
-[Fale com um especialista](javascript:void\(0\))
-
-Potencialize seu negócio com as soluções da Celcoin
-
-[Ver documentação](https://www.celcoin.com.br/developers/)
-
- 
-
-[](https://www.celcoin.com.br)
-
-- Produtos
-
- Close Produtos Open Produtos
-
- cel\_payments
-
- Soluções para todas as etapas da jornada do seu cliente.
-
- - [Débito veicular](https://www.celcoin.com.br/cel_payments/debito-veicular/)
- - [Débito veicular white label](https://www.celcoin.com.br/cel_payments/debito-veicular-white-label/)
- - [Gateway de pagamento](https://www.celcoin.com.br/cel_payments/gateway-de-pagamento/)
-
- - [ITP](https://www.celcoin.com.br/cel_payments/open-finance-itp/)
- - [Pagamento de contas](https://www.celcoin.com.br/cel_payments/pagamento-de-contas/)
- - [Pix](https://www.celcoin.com.br/cel_payments/pix/)
-
- - [Recargas](https://www.celcoin.com.br/cel_payments/recargas/)
- - [Saque e Depósito](https://www.celcoin.com.br/cel_payments/saque-e-deposito/)
-
-
-[Fale com um especialista](javascript:void\(0\))
-
-Potencialize seu negócio com as soluções da Celcoin
-
-Mais autonomia para sua empresa
-
-## Pix com autonomia e tecnologia avançada para sua empresa
-
-Com a Celcoin, você tem acesso à melhor tecnologia de pagamentos instantâneos, aliada à segurança e escalabilidade necessárias para garantir eficiência e conformidade em todas as transações.
-
-### Alta escalabilidade
-
-Nossa infraestrutura garante que você possa processar um grande volume de transações com rapidez e segurança.
-
-### Flexibilidade operacional
-
-Seja com a Embedded Solution de Pix ou através da licença de Pix Indireto, você tem total autonomia para gerenciar as operações de pagamentos e recebimentos, além de toda a gestão de chaves Pix.
-
-### Suporte completo
-
-Desde a integração até o suporte contínuo, estamos prontos para auxiliar sua empresa em todas as etapas do processo.
-
-### Compliance garantido
-
-A Celcoin cuida de toda a conformidade regulatória com o Banco Central, permitindo que sua empresa se concentre no crescimento.
-
-Pix
-
-## O Pix ainda mais conectado à nossa infratech
-
-A Celcoin oferece duas modalidade para sua empresa operar no arranjo Pix,
dependendo de suas necessidades e estrutura.
-
-Finalidade Funcionalidades Benefícios
-
-Empresas que estão começando no arranjo Pix
-
-Disponibilizamos uma conta semelhante à Conta PI, com controle completo de saldos, extratos e limites transacionais, facilitando a gestão da tesouraria de sua empresa.
-
-Empresas com licença do Banco Central
-
-Se sua empresa já possui a licença do Banco Central, fazer a migração para o Pix Indireto da Celcoin oferecerá uma integração simplificada para que você opere com total autonomia, utilizando nossa infraestrutura robusta e segura, que transaciona mais de 250 milhões de Pix todos os meses.
-
-Operação facilitada de tesouraria
-
-Disponibilizamos uma conta semelhante à Conta PI, com controle completo de saldos, extratos e limites transacionais, facilitando a gestão da tesouraria de sua empresa.
-
-Única integração para todo o ciclo de vida
-
-Com apenas uma integração, sua empresa pode iniciar como participante indireto e, futuramente, evoluir para participante direto, sem precisar trocar de infraestrutura.
-
-Acesso completo ao Pix e cabine de gestão
-
-Oferecemos uma cabine de gestão completa, onde sua empresa pode monitorar o fluxo financeiro, gerenciar infrações e devoluções, e visualizar dados estatísticos em tempo real.
-
-Privacidade das chaves DICT
-
-Sua empresa terá controle total sobre a privacidade das chaves Pix, com proteção garantida e sem vínculo com o participante direto.
-
-Alto desempenho e segurança
-
-Com nossa infraestrutura de alto desempenho, sua empresa opera com segurança e escalabilidade, protegendo os dados a nível bancário.
-
-- **Gestão completa de chaves Pix:** Controle total sobre a criação, cancelamento e portabilidade das chaves Pix.
-- **Conformidade garantida:** A Celcoin oferece suporte integral ao processo de homologação com o Banco Central.
-- **Modularidade:** Escolha entre utilizar a arquitetura de contas da sua empresa ou se integrar ao core bancário da Celcoin.
-- **Transparência nas operações:** O nome da sua empresa, como participante indireto, será exibido no comprovante, aumentando a transparência e confiabilidade com seus clientes.
-- **Autonomia operacional:** Sua empresa terá controle total sobre suas operações financeiras, integrando-se diretamente ao SPI do Banco Central.
-- **Suporte 24/7:** Atendimento dedicado para auxiliar sua empresa em todas as etapas, desde o onboarding até a operação contínua, 24 horas por dia, 7 dias por semana.
-
-### Pix Indireto
-
-Tenha acesso a uma solução robusta e escalável, que **permite à sua empresa operar de forma independente como Participante Indireto no arranjo Pix**, sem a necessidade de se conectar diretamente ao Banco Central.
-
-Com isso, você terá maior controle sobre suas operações financeiras, garantindo flexibilidade e eficiência nas transações.
-
- 
-
-### Pix
-
-O Pix é ideal para empresas que buscam uma forma rápida e fácil de oferecer Pix em suas plataformas, **sem se preocupar com a complexidade regulatória ou operacional**.
-
-Disponibilizamos toda a infraestrutura pronta e simplificada para transações instantâneas.
-
- 
-
-Funcionalidades Benefícios
-
-Pix Cash-in
-
-Realize cobranças e receba de forma instantânea
-
-- **QR Code dinâmico:** Para cobranças imediatas e cobranças com data de vencimento.
-- **QR Code estático:** Para valores que não expiram.
-
-Pix Cash-out
-
-Conte com as melhores alternativas para pagamentos e transferências.
-
-- **Pagamentos via QR Code ou Pix Copia e Cola:** Retorno de todos os dados do QR Code, como identificador, descrição e valor.
-
-- **Transferências com Chave Pix ou dados bancários:** Consulta ao DICT, validação dos dados bancários e, assim, retorno das informações para a transferência ser executada.
-- **Devolução Pix:** Permissão para que o valor de uma transação ou pagamento seja devolvido.
-
-- **Rapidez e disponibilidade:** 99% das transações são concluídas em menos de 10 segundos, funcionando 24/7.
-- **Segurança:** Total conformidade com as regulamentações do Banco Central, garantindo a segurança das transações.
-- **Baixa fricção:** Integração rápida e fácil com um único endpoint, simplificando a operação do Pix em sua plataforma.
-- **Praticidade:** A Celcoin cuida de toda a parte regulatória e conformidade com o Banco Central, sem necessidade de sua empresa lidar diretamente com essas obrigações.
-- **Contas individualizadas:** Vinculação de chaves Pix com contas exclusivas para cada cliente.
-- **Grande volume de transações:** Suporte a um número elevado de transações, com segurança e agilidade.
-- **Facilidade de integração:** API fácil de usar, com documentação completa e suporte dedicado.
-
-## Pix Automático
-
-O Pix Automático é a solução ideal para automação de recebimentos de pagamentos recorrentes. Com a autorização do seu cliente, os débitos são feitos automaticamente via Pix.
-
-[Ver caso de uso](https://www.celcoin.com.br/insights/conheca-o-pix-automatico-da-celcoin/)
-
- 
-
- 
-
-Developer Hub
-
-## Tudo o que você precisa para integrar com a nossa solução
-
-Nossa solução foi desenvolvida com foco em facilitar a integração para desenvolvedores, garantindo acesso a toda a infraestrutura da Celcoin.
-
-- Guias rápidos de aplicação
-- Exemplos e amostras de código
-- Webhooks em tempo real
-- Documentações completas
-- Suporte especializado para auxiliar em todas as etapas
-
-[Acesse nossa documentação](https://www.celcoin.com.br/developers/)
-
-## Potencialize seu negócio com o Pix da Celcoin
-
-Ofereça uma solução completa de pagamentos instantâneos para sua empresa.
-
-[Fale com um especialista](javascript:void\(0\))
-
-Potencialize seu negócio com as soluções da Celcoin
-
-- [](https://www.linkedin.com/company/celcoin-financial-hub/)
-- [](https://www.instagram.com/celcoin_/)
-- [](https://x.com/celcoinbr)
-- [](https://www.youtube.com/channel/UCOz8tQnZl3cV4cI0beQ5pYw)
-
-Soluções
-
-- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-- [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-- [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-- [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-- [mybenk](https://www.celcoin.com.br/mybenk/)
-
-[Indústrias](https://www.celcoin.com.br/industrias/)
-
-- [E-commerce e Marketplace](https://www.celcoin.com.br/industrias/marketplace/)
-- [Mercado de Capitais](https://www.celcoin.com.br/industrias/mercado-de-capitais/)
-- [Varejo](https://www.celcoin.com.br/industrias/varejo/)
-
-- ERP
-- Insurance
-- Instituições financeiras
-- Utilities
-
-Empresa
-
-- [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
-- [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
-Recurso
-
-- [Canal de Denúncias](https://www.celcoin.com.br/canal-de-denuncias/)
-- [Compliance e Regulatório](https://www.celcoin.com.br/compliance-e-regulatorio/)
-- [Ouvidoria](https://www.celcoin.com.br/ouvidoria/)
-
-- [Seja um parceiro](https://www.celcoin.com.br/partners/)
-- [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
-- [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
-Conteúdos
-
-- [Eventos](https://www.celcoin.com.br/eventos/)
-- [Insights](https://www.celcoin.com.br/insights/)
-- [News](https://www.celcoin.com.br/news/)
-- [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
-Developers
-
-- [APIs](https://developers.celcoin.com.br/reference)
-- [Documentação](https://developers.celcoin.com.br/docs)
-- [Developers](https://www.celcoin.com.br/developers/)
-- [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-Atendimento Celcoin
-
-De segunda a sexta-feira: das 09h às 18h
-
-Telefone
-
-[(11) 5070-8153](tel:1150708153)
-
-Whatsapp
-
-[(11) 4765-5043](https://wa.me/551147655043)
-
-Suporte
-
-Suporte especializado para ajudar você a extrair o máximo das soluções Celcoin
-
-[Enviar uma solicitação](https://suporte.celcoin.com.br/hc/pt-br/requests/new)
-
-Ouvidoria
-
-De segunda a sexta-feira: das 09h às 17h
-
-Telefone
-
-[0800 591 1852](tel:08005911852)
-
-Soluções
-
-- [cel\_bricks](https://www.celcoin.com.br/cel_bricks/)
-- [cel\_banking](https://www.celcoin.com.br/cel_banking/)
-- [cel\_credit](https://www.celcoin.com.br/cel_credit/)
-- [cel\_payments](https://www.celcoin.com.br/cel_payments/)
-- [mybenk](https://www.celcoin.com.br/mybenk/)
-
-Indústrias
-
-- [E-commerce e marketplace](https://www.celcoin.com.br/industrias/marketplace/)
-- [Mercado de capitais](https://www.celcoin.com.br/industrias/mercado-de-capitais/)
-- [Varejo](https://www.celcoin.com.br/industrias/varejo/)
-
-- ERP
-- Insurance
-- Instituições financeiras
-- Utilities
-
-Empresa
-
-- [Central de ajuda](https://suporte.celcoin.com.br/hc/pt-br)
-- [Contato](https://www.celcoin.com.br/contato-celcoin/?formulario_extendido_celcoin=sim)
-
-Recurso
-
-- [Canal de Denúncias](https://www.contatoseguro.com.br/)
-- [Compliance e Regulatório](https://www.celcoin.com.br/compliance-e-regulatorio/)
-- [Ouvidoria](https://www.celcoin.com.br/ouvidoria/)
-
-- [Seja um parceiro](https://www.celcoin.com.br/partners/)
-- [Sobre nós](https://www.celcoin.com.br/sobre-a-celcoin/)
-- [Trabalhe conosco](https://www.inhire.com.br/carreiras/celcoin/)
-
-Conteúdos
-
-- [News](https://www.celcoin.com.br/news/)
-- [Podcast](https://www.celcoin.com.br/podcast-celcoin/)
-
-Developer
-
-- [APIs](https://developers.celcoin.com.br/reference)
-- [Documentação](https://developers.celcoin.com.br/docs)
-- [Developers](https://www.celcoin.com.br/developers/)
-- [Status da API](https://developers.celcoin.com.br/page/status-page)
-
-### Atendimento Celcoin
-
-De segunda a sexta-feira: das 09h às 18h
-
-## Telefone
-
-[0800 591 1457](tel:5070-8153)
-
-## Whatsapp
-
-[(11) 4765-5043](https://wa.me/551147655043)
-
-[Enviar uma solicitação](https://suporte.celcoin.com.br/hc/pt-br/requests/new)
-
-### Ouvidoria
-
-De segunda a sexta-feira: das 09h às 17h
-
-## Telefone
-
-[0800 591 1852](tel:08005911852)
-
-Celcoin Instituição de Pagamento S.A - 13.935.893/0001-09
-Al. Xingu, 350 – Conj 1604 – Alphaville Industrial Barueri – SP – 06455-030
-
-[
-
-Configuração de cookies
-
-
-
-](https://www.celcoin.com.br/compliance-e-regulatorio/)[
-
-Privacidade e termos
-
-
-
-](https://www.celcoin.com.br/compliance-e-regulatorio/)
-
- 
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://dock.tech/en/solution/banking/",
- "format": "markdown",
- "timeout": 60
-}
-```
-
-**Output:**
-```
- Banking - Dock
-
-
-
-
-
-
-
-
-
-[Dock](https://dock.tech/en/)
-
-[Dock](#!) [Solutions](#!) [Developers](https://developers.dock.tech/) [Content](https://dock.tech/en/fluid/) [Contact](#!)
-
-[](# "click to search")
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-**Dock**
-
-Over 25 years dedicated to democratizing access to financial services.
-
-[About](https://dock.tech/en/about/)
-
-We’re reshaping the financial landscape to empower society.
-
-[Career in Dock](https://dock.tech/en/career/)
-
-Maximize your potential without borders; create innovative solutions for leading brands.
-
-[Press room](https://dock.tech/en/press-room/)
-
-Communicating our true impact and commitment to financial inclusion. Access news and official resources.
-
-**Solutions**
-
-Leverage Brazil's largest portfolio of financial solutions to expand and strengthen your business.
-
-[Banking](https://dock.tech/en/solution/banking)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Cards & Credit](https://dock.tech/en/solution/cards-credit)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Acquiring](https://dock.tech/en/solution/acquiring)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Dock One](https://dock.tech/en/dock-one/)
-
-A comprehensive platform to scale your operations with global reach.
-
-[LATAM Solutions](https://dock.tech/en/solutions-dock-latam/)
-
-Drive innovation and grow your business.
-
-[Solutions Brazil](#!)
-
-Discover the most complete portfolio of financial services.
-
-[Dock One platform](https://dock.tech/en/dock-one/)
-
-A complete platform to scale your operations with global reach.
-
-[Banking](https://dock.tech/en/solution/banking)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Cards & Credit](https://dock.tech/en/solution/cards-credit)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Acquiring](https://dock.tech/en/solution/acquiring)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Dock One](https://dock.tech/en/dock-one/)
-
-A comprehensive platform to scale your operations with global reach.
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/multi-benefit-card/) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado) [Tokenization](https://dock.tech/en/tokenization/)
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-[LATAM Solutions](https://dock.tech/en/solutions-dock-latam/) [Dock Colombia](https://dock.tech/en/countries/colombia/) [Dock Mexico](https://dock.tech/en/countries/mexico/)
-
-[Banking](https://dock.tech/en/solution/banking) [Cards & Credit](https://dock.tech/en/solution/cards-credit) [Acquiring](https://dock.tech/en/solution/acquiring) [Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/multi-benefit-card/) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado) [Tokenization](https://dock.tech/en/tokenization/)
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One platform](https://dock.tech/en/dock-one) [Data Platform](https://dock.tech/en/data-platform)
-
-**Contact**
-
-We are prepared to serve you in the best possible way.
-
-[Speak to the salesperson](https://dock.tech/en/#contato)
-
-To get in touch with our sales team, click here and complete the form.
-
-[Customer service](https://dock.tech/en/sac/)
-
-For frequently asked questions and customer service, click here.
-
-[Media Inquiries](https://dock.tech/en/press-room/#contato-imprensa)
-
-Please reach out to our communications team.
-
-[Dock](https://dock.tech/en/)
-
-[
-
-
-
-
-
-
-
-](#!)
-
-[Dock](#!) [Solutions](#!) [Developers](https://developers.dock.tech/) [Content](https://dock.tech/en/fluid/) [Contact](#!)
-
-[Dock](#!)
-
-Over 25 years dedicated to democratizing access to financial services.
-
-[About](https://dock.tech/en/about/)
-
-We’re reshaping the financial landscape to empower society.
-
-[Career in Dock](https://dock.tech/en/career/)
-
-Maximize your potential without borders; create innovative solutions for leading brands.
-
-[Press room](https://dock.tech/en/press-room/)
-
-Communicating our true impact and commitment to financial inclusion. Access news and official resources.
-
-[Solutions](#!)
-
-Leverage Brazil's largest portfolio of financial solutions to expand and strengthen your business.
-
-[Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Discover our platform](#!) [LATAM Solutions](#!) [Solutions Brazil](#!) [Dock One platform](#!) [Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Discover our platform](#!)
-
-[LATAM Solutions](#!)
-
-Drive innovation and grow your business.
-
-[LATAM Solutions](https://dock.tech/en/es/solutions-dock-latam/)
-
-[Solutions Brazil](#!)
-
-Discover the most complete portfolio of financial services.
-
-[Banking](https://dock.tech/en/solution/banking) [Cards & Credit](https://dock.tech/en/solution/cards-credit) [Acquiring](https://dock.tech/en/solution/acquiring) [Fraud Prevention](https://dock.tech/en/solution/fraud-prevention)
-
-[Banking](#!)
-
-Create your own digital bank and offer payment solutions like Pix.
-
-[Digital account](https://dock.tech/en/solution/banking/#conta-digital) [Pix](https://dock.tech/en/solution/banking/#pix) [Bank slips](https://dock.tech/en/solution/banking/#boletos) [Voucher and top-up marketplace](https://dock.tech/en/solution/banking/#marketplace)
-
-[Cards & Credit](#!)
-
-Offer cards with your brand: credit, debit, global, rewards, and more.
-
-[Card Processing](https://dock.tech/en/solution/cards-credit/#processamento) [Brand License](https://dock.tech/en/solution/cards-credit/#bandeiras) [Credit Card](https://dock.tech/en/solution/cards-credit/#cartao-de-credito) [Private-Label Card](https://dock.tech/en/solution/cards-credit/#cartao-private-label) [Multibenefits Card](https://dock.tech/en/solution/cards-credit/#cartao-multibeneficio) [Global Card](https://dock.tech/en/solution/cards-credit/#cartao-global) [Prepaid and Debit Card](https://dock.tech/en/solution/cards-credit/#cartao-pre-debito) [Payroll-Deductible Card](https://dock.tech/en/solution/cards-credit/#cartao-consignado)
-
-[Acquiring](#!)
-
-End-to-end white-label acquiring solutions to transform your business.
-
-[Acquiring as a service](https://dock.tech/en/solution/acquiring)
-
-[Fraud Prevention](#!)
-
-Authentication, detection, and risk prevention throughout your customer journey.
-
-[Biometric Authentication](https://dock.tech/en/solution/fraud-prevention/#biometria) [Background Check](https://dock.tech/en/solution/fraud-prevention/#background-check) [Transactional Anti-Fraud](https://dock.tech/en/solution/fraud-prevention/#antifraude-transacional) [Multichannel Communication](https://dock.tech/en/solution/fraud-prevention/#comunicacao-multicanal)
-
-[our platform](#!)
-
-A comprehensive platform to scale your operations with global reach.
-
-
-
-
-
-DOCK ONE **Our layered solutions**
-
-Robust high-tech platform, totalmente personalized and modular thanks to our APIs, in addition to taking care of all the bureaucracy, IT, products, regulatory, licensing and prevention of fraude.
-
-[LEARN MORE](https://dock.tech/en/dock-one)
-
-[Contact](#!)
-
-We are prepared to serve you in the best possible way.
-
-[Talk to Commercial](https://dock.tech/en/#contato)
-
-To get in touch with our sales team, click here and complete the form.
-
-[Customer Service](https://dock.tech/en/sac/)
-
-For frequently asked questions and customer service, click here.
-
-[Media Inquiries](https://dock.tech/en/press-room/#contato-imprensa)
-
-Please reach out to our communications team.
-
-
-
-# **Solutions Brazil** Create your own digital bank with your brand: no bureaucracy
-
-Boost your core business and unlock the potential of your enterprise by implementing financial services with our banking platform.
-
-[LEARN MORE](#contato "click to access")
-
- 
-
-## Everything you need in one place
-
-Discover our white-label digital banking platform!
-
-**Digital account**
-
-Offer features like a traditional bank, including a complete digital account, cards, and much more, all personalized with your brand.
-
-[LEARN MORE](#conta-digital)
-
-**Pix**
-
-Leverage the scalability and security of Pix to offer your customers instant and versatile payment methods.
-
-[LEARN MORE](#pix)
-
-**Bank slips**
-
-Provide convenience and security with a widely accepted and easy-to-use payment method, without needing a bank account.
-
-[LEARN MORE](#boletos)
-
-**Voucher Marketplace**
-
-Attract and retain customers with exclusive offers, creating strategic partnerships and expanding your brand's visibility.
-
-[LEARN MORE](#marketplace)
-
-**Digital account**
-
-Offer features like a traditional bank, including a complete digital account, cards, and much more, all personalized with your brand.
-
-[LEARN MORE](#conta-digital)
-
-**Pix**
-
-Leverage the scalability and security of Pix to offer your customers instant and versatile payment methods.
-
-[LEARN MORE](#pix)
-
-**Bank slips**
-
-Provide convenience and security with a widely accepted and easy-to-use payment method, without needing a bank account.
-
-[LEARN MORE](#boletos)
-
-**Voucher Marketplace**
-
-Attract and retain customers with exclusive offers, creating strategic partnerships and expanding your brand's visibility.
-
-[LEARN MORE](#marketplace)
-
-## Digital account
-
-Build your own bank with the white-label Digital Account solution and enjoy the expertise of those who have more than 75 million active accounts.
-
-**White-label digital account**
-
-Offer to your customers a complete experience of a 100% digital account with your brand.
-
-- 
-
- 
-
- Have your own digital account app.
-- 
-
- 
-
- Convenience in bank transfers via Pix, bill payments and slip payments.
-- 
-
- 
-
- Track movements such as revenue, costs and expenses in one place.
-
-**Debit card with your brand**
-
-Transform your brand identity into a personalized card.
-
-- 
-
- 
-
- Offer exclusive benefits tied to the card's usage.
-- 
-
- 
-
- Strengthen your brand presence and loyalty.
-
-
-
-
-
-
-
-
-
-
-
-
-
-**Virtual Card for online shopping**
-
-Ensure more convenience and security for your customers' online payments.
-
-- 
-
- 
-
- Increase convenience in e-commerce shopping.
-- 
-
- 
-
- Dynamic CVV for enhanced transaction security.
-
-**Voucher and mobile top-up marketplace**
-
-Increase your competitive advantage by providing a marketplace for voucher redemption.
-
-- 
-
- 
-
- Diversify your services by including an option for top-ups and voucher redemption.
-- 
-
- 
-
- Create an alternative revenue stream by receiving a percentage of each voucher sold.
-- 
-
- 
-
- Loyalty tool that uses the marketplace for referral and earn-and-burn campaigns.
-
-[LEARN MORE](#contato)
-
-
-
-
-
-
-
-
-
-
-
-
-
-[LEARN MORE](#contato)
-
-## Pix
-
-Allow your customers to make payments quickly and easily! Integrate Brazil's most widely used payment method into your business model with options that meet your needs:
-
-- 
-
- 
-
- **Have your own company Pix:** become an Indirect Pix Participant without needing to be a financial institution, with the autonomy for configuration and customization.
-
-- 
-
- 
-
- **Pix as a payment method:** connect to our API to generate QR Codes (static or dynamic) and keys (copy-and-paste) for payments in physical or virtual environments.
-
-- 
-
- 
-
- **Pix as a bill payment option:** offer QR Codes across multiple channels to process transactions and instantly increase limits.
-
-- 
-
- 
-
- **Pix on your bank slip:** connect to an API to generate bank slips (commercial or service invoices) with the Pix QR Code, reducing costs in payment settlement via barcode.
-
-
-[LEARN MORE ABOUT PIX](#contato)
-
-
-
-
-
-## Successful businesses are already automating collections with Automatic Pix. And you?
-
-With just one authorization from the payer, debits are processed quickly, securely, and frictionlessly, reducing defaults and optimizing financial management, contributing to your business's cash flow, and more:
-
-[LEARN HOW TO INTEGRATE](/en/solution/banking/pix-automatic/)
-
-- 
-
- 
-
- **Flexible scheduling:** weekly, monthly, quarterly, semi-annual or annual charges.
-
-- 
-
- 
-
- **Instant settlement:** values creditdata on time, with full visibility of the operation.
-
-- 
-
- 
-
- **Low operational cost:** without the need for agreements, as with traditional direct debit.
-
-
-
-
-
-
-## Bank slips
-
-Optimize your customers' payments with security and convenience.
-
-- 
-
- 
-
- Solutions for unbanked customers.
-- 
-
- 
-
- Simple, intuitive, and secure.
-- 
-
- 
-
- Reduction in operational costs.
-
-## Bolepix
-
-Expand choice options by offering the method that combines Brazil's most widely used payment methods - Pix and bank slips (boleto).
-
-- 
-
- 
-
- Payments processed in seconds - no need to wait 2 days for clearance.
-- 
-
- 
-
- Easy to use for both issuers and users, as both can use barcodes and Pix QR Codes to make payments.
-- 
-
- 
-
- All the operational security that a bank slip and Pix can offer.
-
-## Voucher and top-up marketplace
-
-The best offers in credits and benefits with exclusive vouchers for your company.
-
-- 
-
- 
-
- **Customer attraction and loyalty:** attract customers interested in benefits such as gift cards, service vouchers, and top-ups.
-
-- 
-
- 
-
- **Targeted marketing:** conduct marketing campaigns promoting partners and exclusive discounts.
-
-- 
-
- 
-
- **Strategic partnerships:** collaborate with other businesses in the marketplace and create strategic partnership opportunities, expanding the customer network and brand visibility.
-
-
-[LEARN MORE](#contato)
-
-
-
-
-
-### Who trusts in our solutions
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## FAQ
-
-What is a white-label digital bank?
-
-A white-label digital bank is a **100% customized bank branded** by a company that partners with a technology provider who develops and supplies the entire financial services infrastructure through APIs. This model enables fintechs and organizations from any sector to have their own bank without needing to build everything from scratch.
-
-How do I get my own white-label digital bank?
-
-To have a white-label digital bank, you need to find a technology provider who offers a banking platform with all the necessary infrastructure, such as Dock. Thanks to the model's flexibility and customization possibilities, the company can have a bank that reflects its visual identity and brand value proposition.
-
-What is Banking as a Service (BaaS)?
-
-Banking as a Service is the solution that allows a company to have its own white-label bank without becoming a bank itself. In BaaS, the infrastructure provider acts as the payment institution and issuer, being responsible not only for technology and security but also for operations, licenses, compliance, and regulatory adherence.
-
-How does a white-label bank work?
-
-A white-label bank works through APIs, which allow the integration of robust services such as digital accounts, card issuance, payment management, etc. It is typically offered in a plug-and-play format, and the company offers its services through the provider's platform, only needing to develop the front-end with its brand.
-
-What are the benefits of a white-label bank?
-
-The benefits of a white-label digital bank include having your own bank without needing to develop infrastructure from scratch, which speeds up implementation and optimizes processes, as the solution is already built, tested, and validated. This also allows the product to be brought to market much faster. Furthermore, a white-label digital bank offers a unique opportunity to expand a company's operations and generate new revenue streams.
-
-What services can a white-label bank offer?
-
-Among the services that a company using the white-label bank model can offer are a complete digital account with different functionalities (Pix, invoice generation, bill payments, top-ups, loans, etc.), its own app, a debit card with its brand, a virtual card for online purchases, and a marketplace for vouchers and top-ups.
-
-Is a banking license required to operate a white-label digital bank?
-
-When operating as a white-label digital bank, the Banking as a Service provider is responsible for both the technical and regulatory aspects, while the contracting party can focus on its core business and on acquiring, engaging, and retaining customers.
-
-What technologies are used in white-label digital banks?
-
-The technologies used in white-label digital banks are based on financial APIs, which function as feature aggregators and are ready to be integrated. The APIs connect the front-end with the digital bank's platform.
-
-How long does it take to launch a white-label digital bank?
-
-The time to launch a white-label digital bank depends on various factors, but it is undoubtedly much shorter than developing a proprietary platform from scratch. Thanks to API technology, Banking as a Service enables a much faster time-to-market for companies that want to have their own bank.
-
-What are the challenges of implementing a white-label digital bank?
-
-Among the challenges of implementing a white-label digital bank is finding the ideal Banking as a Service provider, one that has an adaptable platform and offers everything needed – including treasury, account opening, processing, transaction monitoring, fraud prevention tools, and transactional anti-fraud solutions.
-
-Can I offer Pix in a white-label digital account?
-
-Yes, you can offer Pix in a white-label digital account, allowing users to make transfers and payments quickly and conveniently using the Central Bank's instant payment system.
-
-What are the requirements to offer Pix in a white-label digital account?
-
-To act as an **Indirect Participant of Pix**, you need to be connected to a Direct Participant, like Dock. Furthermore, you need to meet the requirements established by the Central Bank, which include obtaining authorization to act as a financial or payment institution, proving the full subscription and maintenance of at least R$ 5 million in capital, and structuring a minimum compliance program.
-
-How to ensure the security of Pix transactions in a white-label digital account?
-
-Ensuring the security of Pix transactions has been one of the challenges for the Central Bank and the sector as a whole. To minimize risks and protect users and institutions, the CB has been implementing specific measures, such as time restrictions, new device monitoring, and Pix key adjustments. However, institutions must also implement prevention solutions to strengthen protection against fraud.
-
-Is it possible to integrate payment slips (boletos) into a white-label digital account solution?
-
-It is possible to integrate payment slips (boletos) into a white-label digital account solution through specific APIs for this purpose. Dock's Banking solution includes the Boleto functionality, allowing the generation of customized payment slips that include changes to the due date, fines, interest, and discounts.
-
-## Content and events to go further
-
-Discover our exclusive content and events that will unlock even more business potential.
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")
-
-[
-
-Banking
-
-### How to stand out in the financial services sector in a context of multi-banking.
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/payment-initiator/ "Payment initiator and PixWhat changes in the user journey with ITP?")
-
-[
-
-Banking
-
-### Payment initiator and PixWhat changes in the user journey with ITP?
-
-](https://dock.tech/en/fluid/blog/banking/payment-initiator/ "Payment initiator and PixWhat changes in the user journey with ITP?")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/payment-initiator/ "Payment initiator and PixWhat changes in the user journey with ITP?")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/med-2-0/ "MED 2.0: the new era of security. Pix against fraudblows and strikes")
-
-[
-
-Banking
-
-### MED 2.0: the new era of security. Pix against fraudblows and strikes
-
-](https://dock.tech/en/fluid/blog/banking/med-2-0/ "MED 2.0: the new era of security. Pix against fraudblows and strikes")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/med-2-0/ "MED 2.0: the new era of security. Pix against fraudblows and strikes")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/ITP-Open-Finance/ "ITP Open Finance: How the system is revolutionizing the way Brazilians pay.")
-
-[
-
-Banking
-
-### ITP Open Finance: How the system is revolutionizing the way Brazilians pay.
-
-](https://dock.tech/en/fluid/blog/banking/ITP-Open-Finance/ "ITP Open Finance: How the system is revolutionizing the way Brazilians pay.")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/ITP-Open-Finance/ "ITP Open Finance: How the system is revolutionizing the way Brazilians pay.")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/pix-installments/ "Pix Central Bank installment plan: everything about this credit option via Pix")
-
-[
-
-Banking
-
-### Pix Central Bank installment plan: everything about this credit option via Pix
-
-](https://dock.tech/en/fluid/blog/banking/pix-installments/ "Pix Central Bank installment plan: everything about this credit option via Pix")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/pix-installments/ "Pix Central Bank installment plan: everything about this credit option via Pix")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/baas-regulation/ "BaaS Regulation: Central Bank regulates partnerships for offering financial services with Joint Resolution No. 16/2025")
-
-[
-
-Banking
-
-### BaaS Regulation: Central Bank regulates partnerships for offering financial services with Joint Resolution No. 16/2025
-
-](https://dock.tech/en/fluid/blog/banking/baas-regulation/ "BaaS Regulation: Central Bank regulates partnerships for offering financial services with Joint Resolution No. 16/2025")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/baas-regulation/ "BaaS Regulation: Central Bank regulates partnerships for offering financial services with Joint Resolution No. 16/2025")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/how-to-become-a-payment-institution/ "How to become a Payment Institution in Brazil? Learn how to become a PA")
-
-[
-
-Banking
-
-### How to become a Payment Institution in Brazil? Learn how to become a PA
-
-](https://dock.tech/en/fluid/blog/banking/how-to-become-a-payment-institution/ "How to become a Payment Institution in Brazil? Learn how to become a PA")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/how-to-become-a-payment-institution/ "How to become a Payment Institution in Brazil? Learn how to become a PA")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/BaaS-Embedded-Finance/ "BaaS and Embedded Finance: understand the connection between the models and how to leverage this potential in business")
-
-[
-
-Banking
-
-### BaaS and Embedded Finance: understand the connection between the models and how to leverage this potential in business
-
-](https://dock.tech/en/fluid/blog/banking/BaaS-Embedded-Finance/ "BaaS and Embedded Finance: understand the connection between the models and how to leverage this potential in business")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/BaaS-Embedded-Finance/ "BaaS and Embedded Finance: understand the connection between the models and how to leverage this potential in business")
-
-## Contents and events to go further
-
-Discover our content and exclusive events that will unlock even more potential in your business.
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")
-
-[
-
-Banking
-
-### How to stand out in the financial services sector in a context of multi-banking.
-
-](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/multi-banking/ "How to stand out in the financial services sector in a context of multi-banking.")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/benefits-of-bre-b/ "Benefits of Bre-B: Colombia's instant payments system has the potential to boost domestic businesses")
-
-[
-
-Banking
-
-### Benefits of Bre-B: Colombia's instant payments system has the potential to boost domestic businesses
-
-](https://dock.tech/en/fluid/blog/banking/benefits-of-bre-b/ "Benefits of Bre-B: Colombia's instant payments system has the potential to boost domestic businesses")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/benefits-of-bre-b/ "Benefits of Bre-B: Colombia's instant payments system has the potential to boost domestic businesses")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/dimo/ "DiMo and the promise of a revolution in instant payments and financial inclusion in Mexico")
-
-[
-
-Banking
-
-### DiMo and the promise of a revolution in instant payments and financial inclusion in Mexico
-
-](https://dock.tech/en/fluid/blog/banking/dimo/ "DiMo and the promise of a revolution in instant payments and financial inclusion in Mexico")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/dimo/ "DiMo and the promise of a revolution in instant payments and financial inclusion in Mexico")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/immediate-payments/ "Instant Payments: How Bre-B Brings Innovation and Financial Inclusion to the Colombian Ecosystem")
-
-[
-
-Banking
-
-### Instant Payments: How Bre-B Brings Innovation and Financial Inclusion to the Colombian Ecosystem
-
-](https://dock.tech/en/fluid/blog/banking/immediate-payments/ "Instant Payments: How Bre-B Brings Innovation and Financial Inclusion to the Colombian Ecosystem")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/immediate-payments/ "Instant Payments: How Bre-B Brings Innovation and Financial Inclusion to the Colombian Ecosystem")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/new-economy/ "The new economy and the strategic role of embedded finance in business transformation.")
-
-[
-
-Banking
-
-### The new economy and the strategic role of embedded finance in business transformation.
-
-](https://dock.tech/en/fluid/blog/banking/new-economy/ "The new economy and the strategic role of embedded finance in business transformation.")[LEARN MORE](https://dock.tech/en/fluid/blog/banking/new-economy/ "The new economy and the strategic role of embedded finance in business transformation.")
-
-[
-
-
-
-](https://dock.tech/en/fluid/blog/banking/bre-b/ "Bre-B: instant payment system is inspired by Pix and promises to transform Colombia's financial sector")
-
-[
-
-Banking
-
-
-...15881 bytes truncated...
-
-The tool call succeeded but the output was truncated. Full output saved to: /home/alex/.local/share/opencode/tool-output/tool_d62512fde001W15W4pu9YDPg0l
-Use the Task tool to have explore agent process this file with Grep and Read (with offset/limit). Do NOT read the full file yourself - delegate to save context.
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 73.1s)
-
-_Thinking:_
-
-**Analyzing partner setups**
-
-I need to help the user compare their setup with other partners like Dock and Celcoin. Their initial idea was just to use BaaS and perhaps PaaS. Right now, we're in a read-only planning mode. I might analyze Dock's docs, but I wonder if it's really necessary since I've already gathered enough from their public documentation. Maybe I should try to find more specific documents from Dock developers, but I could also consider examining the truncated file from earlier.
-
-_Thinking:_
-
-**Exploring Dock documentation**
-
-The instructions suggest using the Task to let the explore agent process the truncated file with Grep and Read, so I should follow that. I need to analyze the saved Dock page output to find useful information for comparison since the user wants to enhance evidence. While we might already have enough, I could also consider using webfetch for specific Dock pages, especially if they have better developer documentation. It might help to clarify with the user about their comparison needs to provide the best information.
-
-_Thinking:_
-
-**Comparing BaaS and PaaS options**
-
-I want to highlight that if we're looking at just BaaS and possibly PaaS, Celcoin seems like the most suitable option due to its modular BaaS and Pix stack, along with detailed documentation. Z.ro could work too but leans more towards crypto and product focus. However, if we're considering a comprehensive solution like a full white-label bank with cards and acquiring, Dock may be the strongest, though it’s heavier. I think I should separate the analysis for BaaS-only and BaaS+PaaS, and gather more specific details from the Celcoin and Dock documentation as needed.
-
-I have enough to compare the partner shapes. I’m only filling one gap: Dock’s developer and product surface is less public than Celcoin’s, so I’m validating whether we should treat Dock as a fuller white-label bank stack rather than a leaner BaaS/Pix-first partner.
-
-**Tool: task**
-
-**Input:**
-```json
-{
- "description": "Inspect Dock docs",
- "prompt": "You are comparing Dock versus Z.ro and Celcoin for a Brazil fintech launch focused on partner-led custody, employer/employee onboarding, Pix payouts, and optional payment acceptance. Use read-only tools only. Analyze the truncated Dock outputs saved by the environment if helpful, and search Dock's public developer/docs site if possible. Return a concise summary with: 1) what Dock clearly offers publicly, 2) what is missing or less clear from public docs versus Celcoin/Z.ro, 3) whether Dock appears better suited for a full white-label bank/cards/acquiring stack or a lean BaaS+Pix launch, and 4) any evidence for indirect Pix participation, digital accounts, cards, acquiring, fraud tooling, and developer friendliness. Do not modify files.",
- "subagent_type": "explore",
- "thoroughness": "medium"
-}
-```
-
-**Output:**
-```
-task_id: ses_29dae880bffewOqrZVDMBnOSnS (for resuming to continue this task if needed)
-
-
-1) Publicly, Dock clearly offers:
-- A broad embedded-finance stack: Banking, Cards & Credit, Acquiring, Fraud Prevention, and a platform layer called Dock One.
-- Banking modules including Conta Digital, Pix, Boletos, and voucher/recharge marketplace.
-- Card issuing/processing: crédito, débito, pré-pago, private label, benefícios, global, consignado, tokenização.
-- White-label acquiring.
-- Fraud tooling: biometric auth, background check, transaction antifraud, multichannel communication.
-- Strong regulatory/scale claims: “IP regulada e participante direto Pix (código bancário #301)”, 70M active accounts, 1.3B Pix in 12 months, 30+ card brands homologated.
-
-2) What is missing / less clear publicly vs Celcoin/Z.ro:
-- Dock’s public site is much more marketing-led than Celcoin’s docs.
-- I found clear breadth, but less public detail on:
- - API structure/endpoints
- - auth/security model
- - sandbox/homologation flow
- - webhooks/events
- - KYC/onboarding workflows for employer/employee setup
- - explicit Pix indirect-participant support
-- By contrast, Celcoin’s public developer docs are much clearer and deeper on:
- - account opening/KYC
- - Pix cash-in/cash-out
- - Pix Automático
- - Pix Indireto
- - webhooks
- - mTLS, idempotency, rate limits, sandbox/homologation
- - acquiring/subacquiring APIs
-- Z.ro’s public docs are clearer than Dock’s on product surface/navigation, but from what I could fetch they still look lighter than Celcoin in public implementation detail.
-
-3) Best fit:
-- Dock appears better suited publicly for a full white-label bank/cards/acquiring stack than for a lean BaaS+Pix launch.
-- Reason: its strongest public message is “one-stop-shop” breadth across banking + cards + acquiring + fraud + regulatory handling.
-- For a lean Brazil BaaS+Pix launch, Celcoin looks easier to validate from public docs because the operational/API details are more explicit.
-
-4) Evidence by category:
-- Indirect Pix participation:
- - Dock: no public evidence found for indirect participation; public claim is direct Pix participant.
- - Celcoin: explicit public docs for “Pix Indireto.”
-- Digital accounts:
- - Dock: explicit “Conta Digital.”
-- Cards:
- - Dock: very strong evidence; multiple card products and processing/licensing claims.
-- Acquiring:
- - Dock: explicit “Acquiring as a service,” white-label acquiring, 30+ brands homologated.
-- Fraud tooling:
- - Dock: explicit fraud-prevention suite and onboarding-to-transaction monitoring language.
-- Developer friendliness:
- - Dock: some positive signals (“APIs”, developer portal, modular platform), but public self-serve technical depth is less clear than Celcoin.
- - Celcoin: strongest public developer-friendliness evidence.
- - Z.ro: decent public docs presence, but less evidence than Celcoin from what I could fetch.
-
-Bottom line:
-- Dock looks credible and strong for a broad, enterprise-grade embedded-finance stack.
-- If your near-term launch is partner-led custody + onboarding + Pix payouts first, Celcoin is easier to underwrite from public docs.
-- Dock becomes more attractive if you expect to add cards, acquiring, and fraud tooling relatively early.
-
-Local sources checked:
-- /home/alex/projects/payroll/sessions/session-ses_2f39.md
-- /home/alex/.local/share/opencode/tool-output/tool_d6251a3a10019GnQn8F2QdOtdz
-
-If you want, I can turn this into a tighter Dock vs Celcoin vs Z.ro decision table for your exact launch scope.
-
-```
-
----
-
-## Assistant (Plan · GPT-5.4 · 155.3s)
-
-_Thinking:_
-
-**Comparing setup options**
-
-I need to answer the user's request to compare our setup with potential partners like Dock and Celcoin. The initial idea was to use their BaaS and possibly their PaaS. There's a system reminder that we're in read-only mode, so no edits are allowed. I’ll focus on a comparative analysis and mention that our evaluation should target our specific needs. I'll highlight evidence from docs while noting the limitations due to public documentation, especially around Dock.
-
-_Thinking:_
-
-**Providing decision matrix**
-
-I need to create a decision matrix and a recommendation for our BaaS and PaaS launch. From what I've gathered, Celcoin seems like the best fit, followed by Z.ro, with Dock in third place. I want to make sure I consider all the information thoroughly. Our internal documents specify needs like partner-led custody, KYC, and payment acceptance. Celcoin has extensive developer docs, while Dock has a broad stack but less detailed technical info. I need to present this clearly.
-
-_Thinking:_
-
-**Mapping BaaS and PaaS requirements**
-
-I need to define what "BaaS and maybe PaaS" means for our project. For BaaS, that includes regulated custody, user accounts and wallets, KYC/KYB, Pix cash-out, internal transfers, and statements/webhooks. For PaaS, it's about customer payment collection, specifically Pix QR, cards, boletos, and merchant onboarding. I should compare these requirements using this architecture for each partner. It's crucial to clearly outline the specific layers we need to evaluate each potential partner accurately.
-
-_Thinking:_
-
-**Evaluating onboarding options**
-
-I'm looking at the onboarding systems for employer/employee setups, focusing on accounts, wallets, and Pix payouts. I think there’s an optional PaaS layer that might include Pix cash-in, merchant onboarding, or even split payments. What we need to actually build includes a commission engine, internal ledgers, and analytics. I should frame this as a "Best use of partner" table, considering whether we really need full neobank features right now or just BaaS/PaaS options. Celcoin seems to be a good fit, and Z.ro could be simpler but less established.
-
-_Thinking:_
-
-**Comparing key dimensions**
-
-I need to compare the key dimensions for our options. This includes looking at public API completeness, BaaS coverage, PaaS coverage, flexibility to start small, card acquiring depth, regulatory posture, and what we still need to build ourselves.
-
-For scores, Z.ro is a decent option if we want a single provider for BaaS and Pix. Celcoin appears to be the strongest public fit for our needs with extensive documentation. However, Dock might be the best choice if we're considering a full white-label bank and associated services in the long run.
-
-_Thinking:_
-
-**Evaluating transparency and complexity**
-
-I'm noticing that the public docs for some options are less transparent, which could lead to more operational overhead and complexity that might be unnecessary for a lean launch. The user specifically asked about Dock and Celcoin, but I think it could also be beneficial to include Z.ro in the conversation.
-
-I should be careful not to bring in too many other options unless they're relevant. If the user wants, I can also compare QI Tech.
-
-_Thinking:_
-
-**Evaluating payment options**
-
-I'm thinking of using BaaS exclusively, with maybe PaaS for some greenfield merchants. If we want a clean payment-linked commission from the start, going with Celcoin's Pix/PaaS or Z.ro PaaS seems easier since they provide a direct event source. I need to clarify what changes by provider if we go BaaS-only with optional PaaS. I should also inspect the Dock developers' documentation, but there's only a "ReadMe" file available.
-
-_Thinking:_
-
-**Evaluating participant requirements**
-
-I just noticed the FAQ on the site says that to act as an indirect participant, I must connect to a direct participant like Dock and meet certain requirements. This includes having at least R$5 million in capital and a compliance program. That seems strange since not all customers might need this as indirect participants. It looks like Dock is aiming for partners who already have their own compliance maturity, which raises an important concern.
-
-_Thinking:_
-
-**Considering architecture sense**
-
-It sounds like I'm thinking that architecture still holds value, especially with a partner that offers regulated money movement and optional payment acceptance. This means that architecture can effectively integrate with financial services, which is interesting. It seems that ensuring financial regulation and payment options can enhance the overall design and functionality of architectural projects. I'm curious about the implications of this kind of partnership and how it can impact future designs!
-
-_Thinking:_
-
-**Considering BaaS and PaaS options**
-
-I think I need to mention that maybe the user’s structure involves their BaaS and PaaS. If we keep BaaS mandatory and make PaaS optional, it seems Celcoin has the clearest modular separation. Z.ro can do something similar, but the features split for PaaS are narrower in the public eye. Dock has more capabilities but could be overkill, making it a heavier option commercially and operationally.
-
-_Thinking:_
-
-**Considering compression strategy**
-
-I’m checking the length of the tool outputs, and it seems pretty huge! Compression might be helpful here, particularly since the system suggests using it on closed ranges. Since my previous exploration is all closed off, I think it’s a good idea to compress everything from m0001 to m0014 before finalizing. I really want to create an exhaustive summary with all my findings, so let’s definitely do that!
-
-_Thinking:_
-
-**Analyzing banking features**
-
-So, banking here involves digital accounts, various card types, and some fraud detection tools like biometric authentication. Notably, they have impressive stats, like 70 million active accounts and a direct participant code for Pix. The FAQ hints at some regulatory maturity needed for indirect Pix paths. It looks like while their marketing is strong, the public technical documentation isn't as deep compared to competitors like Celcoin. This makes this solution better suited for broader embedded finance rather than a straightforward BaaS+Pix launch.
-
-_Thinking:_
-
-**Exploring modular infratech**
-
-I see that the site presents a modular approach to infrastructure technology with various offerings like cel_banking, cel_payments, and cel_credit. They mention having a PI license and are a direct participant in Pix, claiming impressive monthly transaction volumes. The Pix functionality has two modes for different types of companies, providing options from simple to more complex setups. They also emphasize 24/7 support and operational autonomy, with a management console to facilitate easiness in integrating services. It's an interesting setup!
-
-**Tool: compress**
-
-**Input:**
-```json
-{
- "topic": "Partner Research",
- "content": [
- {
- "startId": "m0001",
- "endId": "m0013",
- "summary": "User first asked: \"I was looking at Z.ro bank at they seem to be able to provide most of the services we need to get started, go over their documentation and tell me exactly what we need. https://zrobank.com/en\" The repo context was reviewed before any conclusions: `docs/core-idea.md`, `docs/brazil-market.md`, and `docs/year-one-roadmap.md` establish the product as Brazil-first `commission infrastructure`, not a neobank/payroll/credit-first product. Core assumptions preserved during research: partner-led custody/compliance; `Pix`-based instant access to earned commissions; internal ledger with `earned`/`available`/`settled`; v1 employer and employee onboarding; employer/employee dashboards; reserves and holdbacks for reversals; cards and stored balances later; credit much later.\n\nResearch then pulled Z.ro public website pages and public developer docs.\n\nZ.ro website/public positioning findings:\n- Main site `https://zrobank.com/en` positions Z.ro as a `developer-first bank` with open APIs.\n- Public solution buckets: `Local Payments`, `Cross-border Payments (eFX)`, `Cryptocurrencies`, `Financial Infratech`, plus country pages for Brazil/Argentina/Chile/Peru.\n- Brazil page highlights: Pix send/receive at scale, exchange, card/digital-wallet acceptance, webhooks, reconciliation, scheduling, static/dynamic QR codes, automated refunds/returns, and a multi-currency digital account.\n- Financial Infratech page highlights: BaaS for fintechs/payment providers/ERP/digital platforms; backoffice for sub-account ecosystems; payment gateway; internet banking; white-label application.\n- Local Payments page highlights: cards, digital wallets, conversion, scale, dashboards, automatic reconciliation, personalized reports.\n- Site credibility claims noted from public pages/media references: payment institution license coverage, A-level company in Brazil Central Bank ranking, audited by EY/KPMG, scale claims, and LATAM presence.\n\nZ.ro developer docs findings:\n- Public docs root: `https://coinwise-io.github.io/zrobank-doc-api/`.\n- Productized API families documented publicly:\n - `Banking as a Service` (`/baas/...`)\n - `Pix as a Service` (`/paas/...`)\n - `Gateway` (`/gateway/...`)\n - `Crypto as a Service`\n- API setup/auth:\n - Credentials are `API ID` + `API Key`.\n - Access token generated from `/auth/signin`; Bearer JWT required for API calls.\n - Publicly documented sandbox base URLs exist for BaaS (`https://api-baas-hml.zrobank.xyz/api`), PaaS (`https://paas-hml.zrobank.xyz/api`), and Gateway (`https://payments-api-hml.zrobank.xyz/api/documentation`).\n - HTTPS required.\n - Request model includes `nonce`, `x-transaction-uuid`, replay protection schemas, and idempotence/replay guidance.\n- BaaS public endpoint surface includes:\n - Pix keys/payments/devolutions/deposits\n - wallets, wallet accounts, operations, reports\n - P2P transfers between master/sub-account wallets\n - user bank accounts\n - legal person onboarding, natural person onboarding, shareholders, legal representatives, company docs, merchant onboarding, company registration\n - cards (virtual/physical/activation/blocking/etc.)\n - scheduled Pix, automatic receiver limits, open finance, cross-border modules\n- PaaS public endpoint surface includes:\n - Pix keys, static/dynamic QR codes, split payments, Pix payments, deposits, wallets, operations, cards, scheduled/recurring Pix, open finance\n- Gateway public docs include:\n - payment/withdraw/refund/KYC webhooks\n - customer bank-account allowlisting for deposits/withdrawals\n - payment webhook payloads with payer/receiver/bank account data\n- Z.ro public onboarding guides were detailed enough to map exact requirements:\n - Legal person onboarding flow: create user account (`POST /users/accounts`), create legal-person onboarding, create shareholders, create legal representatives, upload representative docs (`selfie`, identity doc, qualification declaration; optional income/address proof), upload legal-person docs (`SOCIAL_CONTRACT`, plus `BALANCE_SHEET` or `REVENUE_STATEMENT`, optional KYC/AML policy), finalize, then poll or receive webhook status.\n - Natural person onboarding flow: create user account, create onboarding with address/nationality/PEP and optional occupation/income/patrimony, upload selfie + docs or digital identity, poll or receive webhook status.\n- Z.ro public webhook model (BaaS) includes events like `PAYMENT`, `PAYMENT FAILED`, `DEVOLUTION`, `DEVOLUTION FAILED`, `DEVOLUTION RECEIVED`, `DEPOSIT`, `ONBOARDING FINISHED`, `ONBOARDING REJECTED`, `MERCHANT ONBOARDING KYC STATUS`, `WALLET_ACCOUNT_BALANCE_UPDATED`, and judicial block/unblock events. Webhooks are configured through their team and can support optional auth methods.\n- Specific endpoint facts used in analysis:\n - `POST /v1/operations/p2p-transfers` enables internal transfer between master/sub-account wallets.\n - `GET /v1/users/banking/accounts` returns user bank account details.\n - `POST /v1/cards/virtual` creates virtual cards.\n - `POST /split-payments/pix/qr-codes/static` creates static split Pix QR codes with account-level split instructions.\n - Merchant onboarding endpoint explicitly says it registers a legal person as a commercial establishment at `Dock Acquiring`, which implies some payment-acceptance capability may sit on top of Dock rather than being fully native.\n- Z.ro support/env notes gathered:\n - Public docs mention sandbox and production environments and route support/commercial questions to `meajuda@zrobank.com.br` / `comercial@zrobank.com.br` (plus other emails on docs/site).\n\nConclusion delivered to the user from the Z.ro pass:\n- Z.ro appears able to cover much of the regulated money-movement and onboarding stack needed for the Brazil v1, especially if used `BaaS-first`.\n- What Z.ro can likely provide for this product: partner-led custody/accounts/wallets, employer KYB, employee KYC, Pix payouts/cash-outs, wallet/account operations, internal wallet transfers, statements/reports/reconciliation, webhooks, and later cards.\n- Optional/conditional Z.ro modules: PaaS/Gateway if customer payment acceptance is brought in-house from day one.\n- What Z.ro does **not** replace: the startup’s commission rules engine, internal ledger states (`earned`, `available`, `settled`), reserve/holdback logic, disputes/clawbacks, employer analytics, and the product-specific application layer.\n- What would be needed from Z.ro commercially/technically if chosen:\n - BaaS product/program setup with sandbox + production access, `API ID`, `API Key`, and `product_uuid`\n - employer onboarding/KYB under Z.ro’s flow\n - employee onboarding/KYC under Z.ro’s flow\n - Pix payout flow and internal wallet movement flow\n - webhook registration and reconciliation wiring\n - internal implementation of auth/token management, nonce/transaction UUID generation, idempotent webhook processing\n- Specific open diligence questions identified for Z.ro:\n - whether one master program can hold funds and create segregated employer/employee wallets or whether each employer needs full legal-person account structure\n - whether employees can cash out via Pix without a full Z.ro account or if onboarding is mandatory\n - fees, SLAs, production limits, and webhook guarantees\n - how refunds/devolutions interact with already-moved employee balances\n - whether each employer needs separate merchant onboarding if Gateway/acquiring is used\n\nUser then followed up: \"compare this setup with other potential partners like Dock and Celcoin. The idea I envisioned at first was just using their BaaS and maybe their PaaS.\" Plan/read-only mode became active, so only research/analysis continued.\n\nComparison research gathered public evidence for Dock and Celcoin against the intended architecture: use partner `BaaS` for custody/onboarding/payouts and optionally add `PaaS` / payment-acceptance modules, while still building the proprietary commission engine + internal ledger.\n\nCelcoin public site findings:\n- Celcoin positions itself as `infratech financeira` / embedded-finance infrastructure.\n- Public solution groups include:\n - `cel_banking`: BaaS, liquidating bank, white-label cards, core banking, data sharing/open finance, regulatory support\n - `cel_payments`: Pix, payment gateway, bill pay, ITP, recargas, saque/deposito, etc.\n - `cel_credit`: CCB, escrow, core credit, receivables/credit management\n - `mybenk`: white-label app/web + backoffice\n- Public company-scale claims surfaced: PI license, direct Pix participation, Open Finance roles, large transaction volume, many enterprise customers.\n- Celcoin Pix page specifically states:\n - strong scale/ANS claims for Pix processing\n - two modes: simpler Pix offering for companies getting started and `Pix Indireto` for already licensed companies\n - treasury/account-like controls, complete key management, management console, support, and a path to evolve participant model without replatforming\n- Public site strongly emphasizes modularity and white-label/embedded distribution.\n\nCelcoin developer docs findings (important because they were much more detailed than Dock’s public technical surface):\n- Public developer docs are extensive and navigable via `developers.celcoin.com.br`.\n- Clear docs exist for:\n - credentials/access\n - API security\n - idempotency\n - `mTLS`\n - rate control\n - homologation\n- BaaS/Core docs publicly expose a broad operational surface:\n - onboarding/KYC and account opening\n - account management / listing / status updates / judicial blocks\n - balances, statements, consolidated statement data\n - Pix cash-in by account, random key, individualized keys, static and dynamic QR\n - Pix cash-out by bank account, Pix key, static/dynamic QR\n - split Pix on dynamic QR (immediate/duedate)\n - Pix Automático\n - Pix Inteligente / sweeping accounts\n - Pix Indireto\n - internal transfers between accounts\n - boleto issuance, boleto split, CNAB\n - TED and reconciliation\n - webhooks and webhook management\n - subadquirência / Acquiring-as-a-Service and chargebacks if needed\n - cards and card management\n - Open Finance/ITP and many adjacent modules\n- Celcoin docs therefore gave strong public evidence that a modular `BaaS first, PaaS optional` architecture is feasible with them.\n\nDock public-site findings:\n- Dock positions itself as a broad one-stop shop for financial services.\n- Public solution buckets found on site:\n - `Banking`\n - `Cards & Credit`\n - `Acquiring`\n - `Fraud Prevention`\n - `Dock One` platform\n- Public banking/product claims include:\n - white-label digital account\n - Pix\n - boletos / bolepix\n - debit and virtual cards\n - voucher/top-up marketplace\n - automatic Pix\n- Public cards/acquiring/fraud breadth is much heavier than Z.ro’s publicly visible stack:\n - credit, debit, prepaid, private-label, global, multibenefits, payroll-deductible cards, tokenization\n - white-label acquiring / multiple networks\n - fraud tools such as biometric auth, background check, transaction antifraud, multichannel comms\n- Public scale/regulatory claims include:\n - regulated PI and direct Pix participant (#301)\n - very large account and Pix volume claims\n - 30+ networks / 400+ customers / multi-country presence\n- Important nuance from Dock’s public banking/Pix pages and FAQ:\n - Dock strongly frames itself as a provider for a full white-label bank stack.\n - Some public FAQ language about acting as an `Indirect Participant of Pix` references BC authorization, minimum capital, and compliance requirements, which makes Dock’s public framing feel more enterprise/regulatory-heavy than the lightest outsourced model.\n- Dock’s public developer and API details were much less clear from accessible public pages than Celcoin’s; available public material was far more marketing-led than implementation-led.\n\nState of comparison at the end of this compressed range:\n- The architecture the user described (`BaaS` and maybe `PaaS`) was preserved as the evaluation frame.\n- Preliminary comparison direction based on public materials alone:\n - `Celcoin` appeared strongest for a modular, API-heavy `BaaS first / optional PaaS later` launch because the public technical surface is broad and explicit.\n - `Z.ro` appeared plausible as a leaner one-partner BaaS/Pix option with decent public docs and explicit onboarding/wallet/Pix primitives, but with lighter public breadth than Celcoin and some payment-acceptance signs pointing to Dock underneath.\n - `Dock` appeared strongest as a full embedded-finance / white-label bank + cards + acquiring + fraud stack, but less clearly optimized for the narrowest launch and less transparent publicly on API/onboarding/webhook specifics."
- }
- ]
-}
-```
-
-**Output:**
-```
-Compressed 13 messages into [Compressed conversation section].
-```
-
----
-
-## User
-
-▣ DCP | -146.9K removed, +3.1K summary
-
-│⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿███████│
-▣ Compression #1 -146.9K removed, +3.1K summary
-→ Topic: Partner Research
-→ Items: 13 messages and 40 tools compressed
-
----
-
-## Assistant (Plan · GPT-5.4 · 83.5s)
-
-_Thinking:_
-
-**Evaluating recommendations and plans**
-
-I think we can provide a recommendation with a decision table, outlining what each partner covers and where the risks lie. The plan mode suggests presenting a clear plan and addressing any loose ends. It might help to ask a couple of clarifying questions about the user's priorities, like whether they care more about speed, breadth, or enterprise considerations. I want to offer analysis first to inform our approach. We may not need extra research since our context is already built.
-
-_Thinking:_
-
-**Drafting a comparison and diligence plan**
-
-I should provide a concise comparison and a diligence plan, then ask which direction the user wants to pressure-test next. I may want to check if any documents in the repository mention partner evaluation, like “docs/ideas-for-review” or any relevant market memo. I’ll make sure to keep it simple with flat lists and no nested bullets. The final answer will include sections like **Bottom Line**, **Comparison**, **What Each Partner Covers**, **Recommended Path**, and **Diligence Questions**. I might note that Celcoin seems strongest for BaaS and PaaS, followed by Z.ro and Dock.
-
-_Thinking:_
-
-**Considering product components**
-
-I think I need to mention that our core product requires certain internal components, regardless of our partnerships. This includes things like a commission rules engine, internal ledger states for earnings, and tools for reconciliation.
-
-I'm reflecting on how I might present this information. A decision matrix could work, and while a markdown table is an option, simple bullet points might be more concise. I’m weighing whether to include headers or keep it straightforward without nested bullets. A table could help compare three vendors easily.
-
-_Thinking:_
-
-**Clarifying questions and evaluating options**
-
-I need to consider asking the user some clarifying questions. I could end with two questions: “Do you want to optimize for the fastest v1 with external payment event ingestion, or for owning payment acceptance from day one?” and “Do you expect card support soon?” Since the user wants a comparison, I might provide options first and then ask. I’ll evaluate Dock, Celcoin, and Z.ro based on implementation risk, public evidence, and scope creep, keeping the startup concept in mind.
-
-_Thinking:_
-
-**Evaluating partner options for employee experience**
-
-I realize employee experience is crucial, so I need a partner for accounts, wallets, onboarding, and Pix payouts. If we explore PaaS and acquiring, we’ll require payment acceptance features, like QR codes and possibly split payments, but that’s not essential at the start. When comparing partners, I’ll consider two launch modes: payout-first and acceptance-led. Celcoin stands out for both modes, Z.ro works well for payout-first, and Dock excels in acceptance-led but may be overkill initially.
-
-_Thinking:_
-
-**Ranking partner options for API and onboarding**
-
-When considering public API due diligence, I would rank the partners as follows: Celcoin first, Z.ro second, and Dock third. For onboarding clarity and webhooks, I again have Celcoin as the top choice, Z.ro second, and Dock as uncertain. If I'm looking for simplicity and a leaner partner relationship, Z.ro could be first or second. However, if Z.ro relies on Dock for merchant onboarding, that could complicate things if acceptance is needed right away.
-
-_Thinking:_
-
-**Considering payment acceptance strategy**
-
-I’m thinking about how payment acceptance may partly depend on Dock. First, I should clarify the topology and fees. The Dock offers a full embedded-finance stack, including digital accounts and fraud management, but its public implementation detail is weaker, potentially making it heavier for a version 1 launch.
-
-For the architecture recommendation, I suggest starting with a BaaS-only version unless payment acceptance is crucial. I could also explore using specific partners and considering various paths depending on requirements, based on speed, coverage, and vendor preferences.
-
-_Thinking:_
-
-**Identifying essential modules**
-
-I need to outline exactly what’s necessary, regardless of the partner involved. First, I could list essential modules like KYB for the employer's legal entity and KYC for each employee receiving funds.
-
-The program model might be a master account with segregated balances, and I should consider Pix cash-out options and internal transfers. Other important features would include webhooks, reconciliation, statement exports, and refund handling. If I decide on PaaS, I’ll need to think about merchant onboarding, Pix collections, and chargeback rules for any card transactions.
-
-_Thinking:_
-
-**Formulating open questions for the user**
-
-I need to consider some open questions to ask the user. For instance, do they need to own payment acceptance from the start, or can they begin with employer-provided payment events?
-
-Also, do they want employee cards or stored balances in the first year, or is that unnecessary for now? I'm curious whether they’re prioritizing a quick launch, a broad platform, or minimizing partner concentration risk. Depending on their answers, I might suggest Celcoin and Z.ro or include Dock. I should also outline due diligence steps to follow, like running a 12-question diligence pack and requesting account diagrams.
-
-**Bottom Line**
-
-For the setup you described, `Celcoin` looks like the best public-fit partner for `BaaS first, PaaS optional`.
-
-My current ranking, based on public docs and positioning:
-
-- `BaaS-first payout launch`: `Celcoin` > `Z.ro` > `Dock`
-- `BaaS + payment acceptance from day one`: `Celcoin` > `Dock` > `Z.ro`
-- `Full white-label bank/cards/acquiring roadmap soon`: `Dock` > `Celcoin` > `Z.ro`
-
-**Why**
-
-- `Celcoin` has the clearest public technical surface for the exact stack you want: onboarding, accounts, balances, Pix in/out, internal transfers, webhooks, split Pix, homologation, idempotency, `mTLS`, and optional acquiring/cards.
-- `Z.ro` is a credible leaner option for `BaaS/Pix` first. Its public docs are good enough to map real onboarding and wallet flows. Main caution: public breadth is lighter than Celcoin, and some merchant/acquiring flow appears to sit on top of `Dock Acquiring`.
-- `Dock` looks strongest as a broad embedded-finance platform, not as the narrowest v1 partner. Great if you want banking + cards + acquiring + fraud relatively early, but the public implementation detail is much thinner.
-
-**What You Need From Any Partner**
-
-- employer `KYB`
-- employee `KYC`
-- one master program with segregated employer/employee balances or subaccounts
-- `Pix` payout / cash-out
-- internal balance transfers
-- webhooks and reconciliation
-- statements / reports
-- sandbox / homologation
-- reversal / devolution handling
-- production limits, SLA, support
-- optional `PaaS`: Pix collection, QR, split settlement, merchant onboarding
-
-**What Matters Most**
-
-The real decision is not feature breadth. It is whether the partner can support your balance topology and reversal model:
-
-- employer funds must stay clearly separated
-- employee balances need `earned`, `available`, `settled` treatment in your own ledger
-- reversals/refunds cannot break already-released commissions
-- reserve / holdback mechanics must be possible
-
-That is where vendor risk actually sits.
-
-**Recommended Path**
-
-1. Start `BaaS-first` unless owning payment acceptance is essential on day one.
-2. Use employer payment events or existing PSP data as the commission trigger if possible.
-3. Shortlist `Celcoin` and `Z.ro` first for v1.
-4. Keep `Dock` in the process only if cards, acquiring, or fraud tooling may matter in the first 12-18 months.
-
-**What You Still Must Build**
-
-None of these partners replace your core product:
-
-- commission rules engine
-- internal ledger with `earned`, `available`, `settled`
-- reserve / clawback logic
-- employer controls and analytics
-- employee payout UX
-- reconciliation and ops workflows
-
-**Questions To Ask All Three**
-
-- Can one master program support segregated employer and employee balances?
-- Is full employee onboarding required before any `Pix` payout?
-- How do refunds/devolutions work after funds were internally moved or paid out?
-- Can reserves / held balances be modeled per employer?
-- What webhook auth, retry, and ordering guarantees exist?
-- What are the exact homologation steps and production SLAs?
-- If we add `PaaS`, can the same setup handle merchant onboarding and split settlement?
-
-If you want, I can next turn this into either:
-
-1. a weighted vendor scorecard for your exact v1, or
-2. a diligence questionnaire to send `Celcoin`, `Z.ro`, and `Dock`.
-
----
-
diff --git a/sessions/session-ses_2f37.md b/sessions/session-ses_2f37.md
deleted file mode 100644
index 5da2ffe..0000000
--- a/sessions/session-ses_2f37.md
+++ /dev/null
@@ -1,4121 +0,0 @@
-# Payment handling, instant credits, analytics, refund strategy
-
-**Session ID:** ses_2f37a5ff6ffeAX2nmUc5D93J8e
-**Created:** 3/20/2026, 6:32:57 PM
-**Updated:** 3/20/2026, 6:47:12 PM
-
----
-
-## User
-
-The following texts are from conversations and shared docs between me and a friend discussing the idea, check if these include things that we haven't discussed/considered in the plan here:
-"Here’s a few ideas I have, we’ll add more as time goes:
-
-We sit between customer, company and employee. We handle the payments, so the money goes to our account, we can use something like Banking as a Service to handle the actual banking side of things. Also, we can use something like Stripe or Ayden to handle the payments at first. Our key feature would be the instant crediting of the payments to the employers’ and employees’ accounts. From the get-go we can also offer some basic analytics to both companies and staff. For companies, what we’d show would be something like transaction history that you can filter by employee and time period, with time and more data we can also add projections, refund rate, etc. For employees, what we’d show is something like personal sales history, progress towards targets, also projections, once we have enough data. Some of the more advanced analytics could be offered as an extra service potentially, with some extra stuff like alerts if some employee has had a drop in performance for example. Early on most of our revenue would come from taking a percentage of the processed payments + float. Although, we could offer the commission advances early on, by having them backed by the employers and offering them a share of the fees/interest charged on the advances. As a way to incentivise the companies to keep money with us, we could offer discounted rates once they hit a certain amount, which we could leverage into building the lending aspect of the business, once we have built some reserves. There are companies that have all the card system setup and offer it as a service, which we could use if the bank that we’re using for our bankend doesn’t offer that, which means it wouldn’t take too long nor be too difficult to also offer the cards (not 100% of this claim though)."
-
-The following texts are in response to my friend's point about refunds/cancelations:
-"yup, this is something we have to consider
-there are a couple of ways to go about this
-once we have enough data we can know how often the refund rate is so we can work from that
-what we could do initially is maybe partially pay it out, or simply say "hey this is the amount of commission you've made, you'll be able to take it out in X days"
-if employers, who already know how often these refunds happen, are up for it we can have them back the advance commissions
-and do that thing of splitting the interest/fees with them
-we'd allow the company to set the limits
-maybe we'd have to change the wording of the marketing a bit
-but the essential part of we handle payments and commissions stays
-this actually gives us an opportunity to make even more money from the inherent friction of the system"
-
----
-
-## Assistant (Build · gpt-5.4 · 9.9s)
-
-_Thinking:_
-
-**Assessing relevant documents**
-
-I need to check if I've included all the necessary elements that we haven't discussed yet. Relevant documents might be the core idea, Brazil market analysis, market memo, and the roadmap. I'm also considering the messaging document, but I feel like I might not need to look at AGENTS again since I've already gone through it. Alright, it sounds like it’s time to create a to-do list to organize everything I need to review!
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Read the key planning docs to understand current scope and assumptions",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Compare the user's conversation notes against the documented plan",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Report what is already covered versus new or underexplored ideas",
- "status": "pending",
- "priority": "high"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Read the key planning docs to understand current scope and assumptions",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Compare the user's conversation notes against the documented plan",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Report what is already covered versus new or underexplored ideas",
- "status": "pending",
- "priority": "high"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 7.6s)
-
-_Thinking:_
-
-
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/01-core-idea.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/01-core-idea.md
-file
-1: # Core Idea
-2:
-3: ## One-line thesis
-4:
-5: A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.
-6:
-7: ## The problem
-8:
-9: ### Employers
-10:
-11: - Commission calculation is often manual, delayed, and hard to audit.
-12: - Sales teams ask for informal advances when payroll cycles lag behind real sales activity.
-13: - Finance teams struggle to forecast commission liability and reconcile payouts.
-14: - Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.
-15:
-16: ### Employees
-17:
-18: - A sale can happen today, but the commission may not be usable for days or weeks.
-19: - Early access to money often depends on asking for an informal advance.
-20: - There is rarely a clear view of what has been earned, what is available, and what is still pending.
-21:
-22: ## The product
-23:
-24: The product sits between customer payment collection and employer payout.
-25:
-26: 1. A customer makes a payment.
-27: 2. The platform receives the payment event directly, or receives trusted payment data from a partner.
-28: 3. A commission engine applies employer-defined rules.
-29: 4. The internal ledger allocates balances between employer and employee.
-30: 5. A safe portion of the employee's commission becomes available immediately.
-31: 6. The employee can cash out instantly, and later can also spend from a wallet or card.
-32: 7. The employer gets the remaining balance on a defined settlement schedule.
-33: 8. Both sides get visibility into earnings, payouts, and performance.
-34:
-35: ## Core product layers
-36:
-37: ### 1. Payment collection or orchestration
-38:
-39: - Accept customer payments directly, or integrate with the employer's processor.
-40: - Use payment events as the source of truth for commission creation.
-41:
-42: ### 2. Commission rules engine
-43:
-44: - Support percentage-based, tiered, and custom rules.
-45: - Lock an auditable calculation for every sale or payment event.
-46: - Track exceptions, reversals, and dispute states.
-47:
-48: ### 3. Ledger and balances
-49:
-50: - Maintain an internal double-entry ledger.
-51: - Track at least three states: `earned`, `available`, `settled`.
-52: - Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.
-53:
-54: ### 4. Instant access rails
-55:
-56: - Phase 1: instant bank transfer or `Pix` cash-out.
-57: - Phase 2: stored balance inside the app.
-58: - Phase 3: prepaid or debit card linked to the balance.
-59:
-60: ### 5. Employer analytics
-61:
-62: - Real-time commission liability.
-63: - Sales staff performance based on actual money movement.
-64: - Forecasts for payouts, reserve needs, and commission trends.
-65:
-66: ### 6. Optional later financing layer
-67:
-68: - Employer-backed advances.
-69: - True risk-based credit only after the business has reliable repayment and reversal data.
-70:
-71: ## Recommended money flow
-72:
-73: The safest early structure is partner-led custody.
-74:
-75: - A regulated bank or licensed financial partner holds funds.
-76: - The platform owns the application layer, commission logic, ledger, and payout orchestration.
-77: - Cards, `Pix`, KYC, and regulated money movement are handled through partners.
-78:
-79: Example flow:
-80:
-81: ```text
-82: Customer pays R$1,000
-83: |
-84: v
-85: Partner-held account receives funds
-86: |
-87: v
-88: Commission engine calculates split
-89: |
-90: +-- Employee commission: R$200
-91: +-- Employer balance: R$800
-92: +-- Platform fee and reserve logic applied
-93: |
-94: v
-95: Employee sees commission balance in app
-96: |
-97: +-- Instant cash-out
-98: +-- Hold balance
-99: +-- Later: card spend
-100: ```
-101:
-102: ## Product thesis
-103:
-104: This should not start as a generic wallet, a payroll platform, or a payday loan app.
-105:
-106: The strongest wedge is:
-107:
-108: `real-time commission access tied to actual payment events`
-109:
-110: That positioning matters because it keeps the first product grounded in employer ROI, worker liquidity, and trusted payment data.
-111:
-112: ## Revenue model
-113:
-114: The business should start with software and money movement economics, not balance-sheet lending.
-115:
-116: - Platform or SaaS fee for employers.
-117: - Take rate or processing fee on payment volume.
-118: - Payout fee or bundled payout plan.
-119: - Premium analytics tier.
-120: - Later: interchange from card spend.
-121: - Later: float-sharing or treasury economics if allowed by partner structure.
-122: - Much later: advance fee for employer-backed early access products.
-123:
-124: ## What the company is not
-125:
-126: - Not a general neobank.
-127: - Not a full payroll processor.
-128: - Not a full CRM or sales engagement tool.
-129: - Not a payday lender.
-130:
-131: The company is best understood as `commission infrastructure`.
-132:
-133: ## Phased expansion
-134:
-135: ### Phase 1
-136:
-137: - Payment-linked commission calculation.
-138: - Employer and employee onboarding.
-139: - Ledger with `earned`, `available`, and `settled` states.
-140: - Instant payout access.
-141: - Employer and employee dashboards.
-142:
-143: ### Phase 2
-144:
-145: - Stored balance and wallet behavior.
-146: - Better analytics and forecasting.
-147: - Reserve and holdback controls for refunds and chargebacks.
-148: - Early employer-backed advance logic for selected customers.
-149:
-150: ### Phase 3
-151:
-152: - Card issuance.
-153: - Spend directly from balance.
-154: - More balance retention and interchange revenue.
-155: - Deeper employer integrations.
-156:
-157: ### Phase 4
-158:
-159: - Multi-entity support.
-160: - Broader partner distribution.
-161: - Carefully controlled credit products if the data and regulation support them.
-162:
-163: ## Key risks and guardrails
-164:
-165: ### Regulatory boundary
-166:
-167: - Do not begin by directly holding deposits or acting like an unlicensed financial institution.
-168: - Use a licensed partner for custody and regulated money movement.
-169:
-170: ### Reversals and chargebacks
-171:
-172: - Do not make all commissions instantly withdrawable on day one.
-173: - Use availability rules, reserves, and holdbacks.
-174:
-175: ### Commission disputes
-176:
-177: - Require explicit employer-approved rules.
-178: - Preserve a full audit trail for every calculation and adjustment.
-179:
-180: ### Labor and tax treatment
-181:
-182: - Distinguish `earned access` from `credit`.
-183: - Map payroll, withholding, and deduction obligations with counsel before product launch.
-184:
-185: ### Partner dependence
-186:
-187: - Expect early dependence on bank, card, and processor partners.
-188: - Build the ledger and business logic so the company can swap infrastructure providers later.
-189:
-190: ## Current strategic recommendation
-191:
-192: - Start in Brazil.
-193: - Lead with `Pix`-based instant access to earned commissions.
-194: - Use partner-led custody and compliance.
-195: - Treat stored balances and cards as retention tools, not the initial wedge.
-196: - Treat employer analytics as a second major value driver.
-197: - Delay true lending until the core ledger and payout engine are reliable.
-
-(End of file - total 197 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/02-brazil-market.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/02-brazil-market.md
-file
-1: # Tese para o mercado brasileiro
-2:
-3: ## Resumo
-4:
-5: A melhor entrada para esta ideia no Brasil e uma plataforma B2B2C que conecta recebimento, calculo de comissao, ledger interno e acesso instantaneo ao saldo via `Pix`.
-6:
-7: O produto inicial nao deve ser vendido como banco digital nem como credito ao consumidor. A tese mais forte e:
-8:
-9: `transformar cada venda validada em saldo de comissao disponivel quase em tempo real`
-10:
-11: ## Por que o Brasil primeiro
-12:
-13: - `Pix` ja criou expectativa de movimentacao instantanea e barata.
-14: - O mercado convive com atraso no pagamento de comissoes e com o uso informal de `vales`.
-15: - Existem instituicoes financeiras, cooperativas, BaaS e emissores abertos a parcerias.
-16: - Ha muitos segmentos com equipes comerciais comissionadas e operacao digital crescente.
-17: - O argumento de valor e simples: menos atraso, menos friccao operacional e mais retencao do time de vendas.
-18:
-19: ## Dor local que o produto resolve
-20:
-21: ### Para a empresa
-22:
-23: - Calculo manual de comissao.
-24: - Fechamento mensal demorado.
-25: - Falta de visibilidade sobre passivo de comissao.
-26: - Uso informal de `vales`, com pouca governanca.
-27: - Dificuldade para reconciliar recebimento, comissao, estorno e repasse final.
-28:
-29: ### Para o vendedor
-30:
-31: - Venda feita hoje, dinheiro disponivel so dias ou semanas depois.
-32: - Dependencia de `vale` para cobrir caixa pessoal.
-33: - Falta de transparencia sobre o que foi ganho, o que esta disponivel e o que ainda esta pendente.
-34:
-35: ## ICP inicial
-36:
-37: O foco deve ser empresas brasileiras com time comercial comissionado e recebimento digital identificavel.
-38:
-39: Segmentos promissores:
-40:
-41: - franquias e operacoes de varejo com vendedores comissionados
-42: - clinicas de estetica, odontologia e procedimentos eletivos
-43: - academias e servicos recorrentes com equipe de vendas
-44: - escolas, cursos e educacao privada com captacao comercial
-45: - telecom, distribuicao e revendas com metas e bonificacao variavel
-46:
-47: ## Proposta de valor no Brasil
-48:
-49: ### Para a empresa
-50:
-51: - Automatizar o calculo e o repasse de comissoes.
-52: - Reduzir dependencia de `vales` informais.
-53: - Melhorar retencao e motivacao do time.
-54: - Ter visao confiavel de performance comercial e custo de comissao.
-55: - Ganhar previsibilidade de caixa e de passivo.
-56:
-57: ### Para o colaborador
-58:
-59: - Ver a comissao quase em tempo real.
-60: - Sacar instantaneamente via `Pix` quando o saldo estiver disponivel.
-61: - Ter mais clareza sobre metas, historico e projecao de ganhos.
-62: - No futuro, usar saldo por cartao sem precisar sacar tudo.
-63:
-64: ## Produto recomendado para o Brasil
-65:
-66: ### V1
-67:
-68: - recebimento via parceiros de pagamento
-69: - motor de regras de comissao
-70: - ledger com estados `ganho`, `disponivel` e `liquidado`
-71: - saldo para colaborador e empresa
-72: - saque instantaneo via `Pix`
-73: - dashboard basico para empresa e vendedor
-74: - trilha de auditoria por transacao, comissao e ajuste
-75:
-76: ### V2
-77:
-78: - saldo retido em carteira
-79: - analytics de performance e passivo de comissao
-80: - regras de reserva para estorno e chargeback
-81: - alertas e projecoes
-82: - piloto de adiantamento com respaldo do empregador
-83:
-84: ### V3
-85:
-86: - cartao prepago ou debito
-87: - maior retencao de saldo na plataforma
-88: - integracoes com ERP, POS, CRM ou software vertical
-89:
-90: ## Parceiros locais que importam
-91:
-92: ### Infra financeira
-93:
-94: - instituicao de pagamento, banco parceiro ou BaaS para custodia e movimento regulado
-95: - exemplos de infraestrutura para avaliar: `Dock`, `QI Tech`, `Celcoin`
-96: - cooperativas e bancos menores podem ser parceiros comerciais ou institucionais, incluindo nomes como `Sicredi`, dependendo do modelo
-97:
-98: ### Processamento de pagamentos
-99:
-100: - parceiros para `Pix`, boleto e cartao
-101: - exemplos para avaliar: `Pagar.me`, `Stripe BR`, `Adyen`
-102:
-103: ### Emissao de cartao
-104:
-105: - exemplos para avaliar: `Dock`, `Pomelo`, `Swap`
-106:
-107: ### KYC e KYB
-108:
-109: - exemplos para avaliar: `idwall`, `BigDataCorp`
-110:
-111: ### Juridico e regulatorio
-112:
-113: - escritorio com experiencia em instituicao de pagamento, arranjos de pagamento, `Pix`, LGPD e temas trabalhistas
-114:
-115: ## Consideracoes regulatorias
-116:
-117: O produto encosta em varias frentes e precisa de mapeamento juridico desde cedo.
-118:
-119: - Banco Central: estrutura de `Pix`, conta transacional, instituicao de pagamento, regras de reporte e compliance.
-120: - Direito do trabalho: natureza da comissao, reflexos em folha, desconto de adiantamentos, regras contratuais com empregador.
-121: - LGPD: dados financeiros e de performance do colaborador.
-122: - CDC e transparencia: fees, prazos, disponibilidade e regras de estorno.
-123:
-124: Recomendacao pratica:
-125:
-126: - comecar debaixo da licenca e da infraestrutura de um parceiro regulado
-127: - evitar custodia direta no inicio
-128: - evitar vender o produto inicial como emprestimo
-129:
-130: ## Como tratar `vales`
-131:
-132: No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.
-133:
-134: Sequencia recomendada:
-135:
-136: 1. acesso ao que ja foi ganho e validado
-137: 2. liberacao conservadora de parte do saldo antes da liquidacao total
-138: 3. adiantamento com respaldo do empregador
-139: 4. so depois, se fizer sentido, credito com underwriting proprio
-140:
-141: Mensagem correta:
-142:
-143: - nao: `emprestimo para vendedor`
-144: - sim: `acesso controlado a comissao ja gerada`
-145:
-146: ## Go-to-market no Brasil
-147:
-148: ### Primeiro movimento
-149:
-150: - fechar 5 a 10 design partners com dor forte de comissao e operacao relativamente simples
-151: - priorizar empresas em que o evento de venda e facil de mapear ao pagamento
-152: - vender para dono, financeiro, operacoes e gestor comercial
-153:
-154: ### Canais de distribuicao
-155:
-156: - venda direta para SMB e mid-market
-157: - parceria com software vertical, POS e adquirencia
-158: - grupos de franquia
-159: - escritorios contabeis e consultorias de operacao ou folha
-160:
-161: ### Pitch inicial
-162:
-163: - reduza trabalho manual no fechamento de comissoes
-164: - de ao time acesso mais rapido ao que ja foi ganho
-165: - troque `vales` informais por um processo auditavel
-166: - tenha visao em tempo real de performance e passivo de comissao
-167:
-168: ## Modelo economico mais provavel
-169:
-170: - fee de plataforma para a empresa
-171: - fee por volume processado ou por pagamento conciliado
-172: - fee por saque, ou plano com franquia de saques
-173: - camada premium de analytics
-174: - depois: interchange de cartao
-175: - depois: compartilhamento de economia financeira, se permitido pelo arranjo com parceiro
-176:
-177: ## Principais riscos no mercado brasileiro
-178:
-179: - estorno ou chargeback depois da liberacao da comissao
-180: - disputa entre empresa e vendedor sobre regra de comissao
-181: - dependencia excessiva de um parceiro bancario ou de BaaS
-182: - classificacao regulatoria errada do produto
-183: - onboarding ruim para empresa e colaborador
-184:
-185: ## Tese final para o Brasil
-186:
-187: O melhor posicionamento nao e `mais um app de EWA` e nem `mais um banco digital`.
-188:
-189: O melhor posicionamento e:
-190:
-191: `a infraestrutura de comissao em tempo real para empresas brasileiras, com saldo disponivel via Pix e visibilidade operacional para o empregador`
-
-(End of file - total 191 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/03-market-memo.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/03-market-memo.md
-file
-1: # Market Memo
-2:
-3: ## Thesis
-4:
-5: There is a clear product gap between commission software, faster worker payouts, and Brazil-native embedded finance.
-6:
-7: Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a Brazil-first platform built around real-time commission availability.
-8:
-9: ## The gap in the market
-10:
-11: Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and informal employee advances. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
-12:
-13: Existing vendors tend to split into separate categories:
-14:
-15: - faster pay or earned wage access
-16: - payout rails and disbursement infrastructure
-17: - commission calculation and analytics software
-18: - employee wallet or card experiences
-19: - Brazil payment and card infrastructure
-20:
-21: The opportunity is to combine these into a single workflow built around a verified payment event.
-22:
-23: ## Competitor map
-24:
-25: | Company | What it does well | Missing piece relative to this idea |
-26: |---|---|---|
-27: | `DailyPay` | Earned wage access, employee liquidity, employer integrations | Not centered on payment-linked commissions or commission-heavy teams |
-28: | `Branch` | Workforce payments, employee app, card, embedded finance | More generic worker finance than commission-specific infrastructure |
-29: | `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system and Brazil-specific positioning |
-30: | `Hyperwallet` | Global payout orchestration | Infrastructure layer, not a commission system of record |
-31: | `CaptivateIQ` | Commission calculation, visibility, forecasting | No native money movement or worker access to balances |
-32: | `Caju` | Brazil employee finance and card experience | Not the source of truth for commission creation and payout logic |
-33: | `Dock` | Brazil financial infrastructure for accounts, cards, `Pix` | Not a direct competitor; more likely an enabling layer |
-34:
-35: ## What is differentiated here
-36:
-37: The strongest version of this company is not just a wallet and not just an analytics tool.
-38:
-39: It is:
-40:
-41: `a commission ledger that turns verified sales into immediately usable balances`
-42:
-43: That positioning changes the product in important ways:
-44:
-45: - the source of truth is a payment event, not a later payroll export
-46: - the employer gets workflow, controls, and analytics
-47: - the employee gets liquidity without relying on informal advances
-48: - the company can monetize software, payment flow, and later retained balances
-49:
-50: ## Why Brazil first
-51:
-52: Brazil is the more compelling launch market than Switzerland for this specific thesis.
-53:
-54: - `Pix` makes instant access behaviorally normal.
-55: - Informal paycheck advances or `vales` create a visible pain point.
-56: - Smaller financial institutions and infrastructure partners may be more open to collaboration.
-57: - Commission-heavy SMB and mid-market businesses are common.
-58: - The value proposition is concrete and easy to explain.
-59:
-60: Switzerland may still matter later, but Brazil provides the clearer wedge, larger behavioral advantage, and stronger infrastructure fit for instant commission access.
-61:
-62: ## Recommended wedge
-63:
-64: The initial product should avoid trying to become a broad payroll platform or a credit-led consumer app.
-65:
-66: The recommended wedge is:
-67:
-68: - process or reconcile customer payments
-69: - calculate commissions in real time
-70: - make a safe portion of earned commissions available immediately
-71: - let workers cash out via `Pix`
-72: - give employers dashboards, controls, and reporting
-73:
-74: This creates value for both sides without requiring the company to start as a full lending business.
-75:
-76: ## Differentiation versus adjacent players
-77:
-78: ### Versus `DailyPay` and `Branch`
-79:
-80: - lead with real-time commission access, not generic earned wage access
-81: - use payment-triggered earnings instead of payroll-cycle files
-82: - speak directly to commission-heavy employers
-83:
-84: ### Versus `CaptivateIQ`
-85:
-86: - move from commission visibility to commission execution
-87: - turn calculation into money movement and employee utility
-88:
-89: ### Versus `PayQuicker` and `Hyperwallet`
-90:
-91: - own employer workflows and analytics, not just disbursement rails
-92: - focus on Brazil-native behavior and infrastructure
-93:
-94: ### Versus `Caju`
-95:
-96: - own the commission event and payout logic, not only the employee finance interface
-97:
-98: ## Business model
-99:
-100: The business should start with software and movement fees, then layer in higher-margin economics over time.
-101:
-102: Early revenue:
-103:
-104: - employer platform fee
-105: - payment or reconciliation take rate
-106: - payout fee or bundled payout plan
-107: - analytics tier for larger employers
-108:
-109: Later revenue:
-110:
-111: - interchange from card spend
-112: - float-sharing or treasury economics if allowed by partner structure
-113: - employer-backed advance fees
-114:
-115: The key is to avoid depending on balance-sheet lending to make the model work.
-116:
-117: ## Go-to-market
-118:
-119: ### Target customers
-120:
-121: - Brazil-based SMB and mid-market employers with commission-heavy teams
-122: - businesses where payment events are digital and attributable
-123: - verticals such as franchise retail, clinics, education, auto, telecom, and other sales-led operations
-124:
-125: ### Buyer
-126:
-127: - owner
-128: - finance lead
-129: - operations lead
-130: - sales manager
-131:
-132: ### Core pitch
-133:
-134: - reduce manual commission work
-135: - reduce informal advances
-136: - help retain and motivate sales staff
-137: - create a trusted real-time view of commission liability and performance
-138:
-139: ### Distribution channels
-140:
-141: - direct sales to design partners
-142: - vertical SaaS and POS partnerships
-143: - franchise groups
-144: - accounting and payroll-adjacent referral channels
-145:
-146: ## Defensibility
-147:
-148: If the company succeeds, defensibility should come from workflow ownership and data position rather than pure infrastructure.
-149:
-150: - payment-linked truth rather than self-reported sales data
-151: - employer-configured commission logic embedded in operations
-152: - worker adoption through payout utility and later card usage
-153: - analytics built on actual money movement
-154: - multi-layer monetization across software, payments, and retention tools
-155:
-156: ## Key risks
-157:
-158: - payment reversals after employee funds are made available
-159: - employer disputes over commission rules
-160: - regulatory boundaries around custody, wage access, and credit
-161: - dependence on a single bank, BaaS, or card partner
-162: - low balance retention if the product offers no reason to keep funds in-platform
-163:
-164: ## Bottom line
-165:
-166: This idea is attractive because it sits in the overlap of three proven categories: commission software, worker liquidity, and embedded finance.
-167:
-168: The market does not appear empty, but it still looks fragmented. A Brazil-first product that turns every validated sale into an auditable, instantly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.
-
-(End of file - total 168 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md
-file
-1: # Positioning and Landing Copy
-2:
-3: ## Core positioning
-4:
-5: This company should not present itself as a generic earned wage access app.
-6:
-7: The stronger frame is:
-8:
-9: `commission infrastructure for real-time sales teams`
-10:
-11: ## Category statement
-12:
-13: We help employers turn verified sales into instantly accessible commission balances, with employer controls, worker payouts, and performance visibility built into one system.
-14:
-15: ## Short positioning line
-16:
-17: Turn every sale into an instantly usable commission balance.
-18:
-19: ## Headline options
-20:
-21: 1. Turn every sale into an instantly accessible commission.
-22: 2. Give sales teams instant access to earned commissions.
-23: 3. Real-time commissions for modern sales teams.
-24: 4. The fastest way to move from customer payment to salesperson payout.
-25: 5. Commission payouts, employer controls, and worker access in one platform.
-26:
-27: ## Subhead options
-28:
-29: 1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.
-30: 2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.
-31: 3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.
-32:
-33: ## Product pillar copy
-34:
-35: ### Real-time commission engine
-36:
-37: Calculate commissions from verified payment events instead of waiting for payroll cycles and spreadsheet reconciliations.
-38:
-39: ### Instant worker access
-40:
-41: Give employees access to eligible commission balances right away, starting with instant cash-out and later expanding to wallet and card spend.
-42:
-43: ### Employer control and auditability
-44:
-45: Set payout rules, track reserve logic, and keep a reliable audit trail across every sale, split, payout, and adjustment.
-46:
-47: ### Payment-linked performance data
-48:
-49: See team performance, commission liability, and payout trends from real money movement rather than disconnected reporting tools.
-50:
-51: ## Employer value props
-52:
-53: - Reduce manual commission operations.
-54: - Replace informal advances with a controlled workflow.
-55: - Improve salesperson retention and motivation.
-56: - Get a clearer view of commission cost and team performance.
-57: - Create a better employee experience without building internal fintech operations.
-58:
-59: ## Employee value props
-60:
-61: - See what you have earned sooner.
-62: - Access eligible commissions faster.
-63: - Stop relying on informal paycheck advances.
-64: - Track progress and earnings in one place.
-65: - Later, spend directly from your balance.
-66:
-67: ## Messaging to avoid
-68:
-69: - Avoid describing the product as a payday loan.
-70: - Avoid leading with float economics or holding customer cash.
-71: - Avoid broad claims about replacing payroll or becoming a bank.
-72:
-73: ## Best narrative arc for a homepage
-74:
-75: ### Hero
-76:
-77: Headline plus a subhead focused on real-time commission access.
-78:
-79: ### Problem section
-80:
-81: Show the old flow: sale now, commission later, advance requests in between.
-82:
-83: ### Solution section
-84:
-85: Show the new flow: payment event, commission split, available balance, instant access.
-86:
-87: ### Employer section
-88:
-89: Focus on automation, controls, and analytics.
-90:
-91: ### Employee section
-92:
-93: Focus on liquidity, visibility, and trust.
-94:
-95: ### Proof section
-96:
-97: Use three proof points:
-98:
-99: - built around verified payment events
-100: - instant payout access
-101: - auditable employer controls
-102:
-103: ### CTA section
-104:
-105: Push a design-partner conversation, not a self-serve signup.
-106:
-107: ## CTA options
-108:
-109: 1. Talk to us about your commission workflow.
-110: 2. See how real-time commission payouts could work for your team.
-111: 3. Become a design partner.
-112: 4. Explore a commission infrastructure demo.
-113:
-114: ## Sample hero copy
-115:
-116: ### Option A
-117:
-118: Headline: Turn every sale into an instantly accessible commission.
-119:
-120: Subhead: We help commission-heavy businesses calculate payouts from real payment events, give teams faster access to eligible earnings, and keep employer controls and visibility in one place.
-121:
-122: CTA: Become a design partner
-123:
-124: ### Option B
-125:
-126: Headline: Real-time commissions for modern sales teams.
-127:
-128: Subhead: Replace delayed commission cycles and informal advances with a payment-linked ledger, instant payout access, and cleaner employer operations.
-129:
-130: CTA: See the workflow
-131:
-132: ## Elevator pitch
-133:
-134: We are building the financial operating layer between customer payments and salesperson earnings. Employers get automated commission calculation and better visibility. Sales teams get faster access to earned commissions. The result is a more trusted, more useful, and more immediate commission system.
-
-(End of file - total 134 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/05-roadmap-12-months.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md
-file
-1: # 12-Month Roadmap
-2:
-3: ## Guiding principle
-4:
-5: Do not start by building a broad neobank or a consumer lending app.
-6:
-7: Start with the smallest product that proves the core wedge:
-8:
-9: `payment-linked commission calculation plus instant access to earned balances`
-10:
-11: ## Success goal for year one
-12:
-13: By the end of 12 months, the company should prove that employers will adopt a commission-led payout workflow and that employees will use it for faster access to earnings.
-14:
-15: The year-one target is not maximum feature breadth. It is proof of product-market fit for the core loop.
-16:
-17: ## Phase 0: Foundation and partner design
-18:
-19: ### Months 0-2
-20:
-21: #### Objectives
-22:
-23: - validate the first customer segment
-24: - choose partner model for custody, payouts, and compliance
-25: - lock the ledger and commission system design
-26:
-27: #### Workstreams
-28:
-29: - run design-partner interviews with target employers
-30: - map employer commission workflows and exception cases
-31: - choose payment and banking partner shortlist
-32: - define balance states: `earned`, `available`, `settled`
-33: - define reserve and holdback logic for reversals
-34: - specify onboarding flows for employers and employees
-35:
-36: #### Deliverables
-37:
-38: - product requirements for v1
-39: - legal and regulatory issue map
-40: - partner shortlist and integration plan
-41: - event model for payments, commissions, adjustments, and payouts
-42:
-43: #### Exit criteria
-44:
-45: - 5 to 10 serious design partners in pipeline
-46: - clear v1 scope that does not depend on lending
-47: - chosen path for `Pix` and custody infrastructure
-48:
-49: ## Phase 1: Core ledger and instant payout access
-50:
-51: ### Months 2-5
-52:
-53: #### Objectives
-54:
-55: - launch the first working employer flow
-56: - prove that a verified sale can become an eligible commission balance
-57: - enable instant cash-out for employees
-58:
-59: #### Product scope
-60:
-61: - employer onboarding
-62: - employee onboarding through partner KYC
-63: - payment ingestion or payment reconciliation
-64: - commission rules engine
-65: - internal ledger
-66: - employee balance with `earned`, `available`, and `settled`
-67: - employer settlement scheduling
-68: - instant payout access via `Pix` or equivalent instant transfer rail
-69: - employer dashboard with payout and commission views
-70: - employee dashboard with balance and payout history
-71:
-72: #### Operational scope
-73:
-74: - manual support for edge cases
-75: - conservative limits on instant availability
-76: - dispute and adjustment workflows
-77:
-78: #### Metrics
-79:
-80: - number of active employers
-81: - commission volume processed
-82: - payout latency
-83: - adjustment and reversal rate
-84: - employee activation rate
-85:
-86: ## Phase 2: Analytics and stored balance
-87:
-88: ### Months 5-8
-89:
-90: #### Objectives
-91:
-92: - make the product more valuable to employers
-93: - improve employee retention of balances
-94: - reduce the need for manual reporting
-95:
-96: #### Product scope
-97:
-98: - stored balance in the app
-99: - clearer balance segmentation and reserve visibility
-100: - employer analytics for team performance and commission liability
-101: - projections for upcoming payouts
-102: - employee insights on earnings pace and history
-103: - alerts for anomalies and budget spikes
-104: - admin tools for corrections and policy configuration
-105:
-106: #### Metrics
-107:
-108: - percent of balances retained in-platform
-109: - dashboard usage by employers
-110: - frequency of manual interventions
-111: - repeat payout behavior per employee
-112:
-113: ## Phase 3: Card and retention tools
-114:
-115: ### Months 8-10
-116:
-117: #### Objectives
-118:
-119: - make the balance more useful without requiring immediate cash-out
-120: - unlock interchange economics
-121:
-122: #### Product scope
-123:
-124: - prepaid or debit card issuance through a partner
-125: - spend from available balance
-126: - card controls and transaction views
-127: - balance retention incentives tied to usage, not explicit interest promises
-128: - stronger notifications and mobile experience
-129:
-130: #### Metrics
-131:
-132: - card activation rate
-133: - card spend volume
-134: - balance retention before and after card launch
-135: - support load per active user
-136:
-137: ## Phase 4: Scale features and controlled advance pilot
-138:
-139: ### Months 10-12
-140:
-141: #### Objectives
-142:
-143: - deepen product value for employers
-144: - test a tightly controlled version of advance functionality without becoming credit-led
-145:
-146: #### Product scope
-147:
-148: - multi-entity or franchise support
-149: - API or integration layer for ERP, CRM, or POS tools
-150: - employer cash flow forecasting
-151: - pilot of employer-backed advances with strict limits
-152: - improved risk rules for refunds, clawbacks, and employee exits
-153:
-154: #### Metrics
-155:
-156: - employer expansion within existing accounts
-157: - integration adoption
-158: - advance usage and repayment behavior
-159: - loss or exception rate on pilot advances
-160:
-161: ## What should stay out of scope in year one
-162:
-163: - standalone consumer lending
-164: - full payroll replacement
-165: - broad international expansion
-166: - feature-heavy consumer banking experience
-167: - deep CRM functionality
-168:
-169: ## Year-one product philosophy
-170:
-171: The roadmap should stay disciplined.
-172:
-173: - build the commission ledger first
-174: - prove instant access to earned money second
-175: - add retention tools third
-176: - add credit only after the company has the data and controls to support it
-177:
-178: ## Recommended milestone sequence
-179:
-180: 1. prove employer demand for payment-linked commission automation
-181: 2. prove worker demand for instant access to eligible balances
-182: 3. prove safe operating rules around reversals and disputes
-183: 4. prove that analytics improves employer retention
-184: 5. prove that cards increase balance retention
-185: 6. only then test employer-backed advance products
-
-(End of file - total 185 lines)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 25.8s)
-
-_Thinking:_
-
-**Exploring payment processing features**
-
-I see that we sit between customers, companies, and employees while handling payments. Initially, we could use services like Stripe or Adyen, with Banking-as-a-Service (BaaS) for banking. A key feature would be instantly crediting payments to accounts while offering basic analytics. Companies would benefit from filtering transaction histories and tracking refund rates, while employees could track their sales and performance. There’s potential for advanced analytics as an extra service, alongside early revenue from processed payments and commission advances. This leads into incentives for companies to keep their funds with us.
-
-_Thinking:_
-
-**Considering card solutions and refunds**
-
-I’m thinking about using a card system through a third-party service if our banking partner doesn't provide that option. For refunds and cancellations, once we gather enough data, we can analyze the refund rate. Initially, we might consider partially paying out refunds or requiring a waiting period for withdrawal. If employers are aware of the refund frequency, they could support advancing commissions. We can split interest and fees, allowing companies to set their limits. Overall, there’s potential to capitalize on payment and commission handling. I'll need to check the plan documents to see what coverage exists.
-
-_Thinking:_
-
-**Considering revenue strategies**
-
-I’m pondering how to approach alerts for employee performance drops—it's not explicitly outlined, but anomaly alerts fit part of that picture.
-
-Early revenue could come from processed payments and different fees like platform, payout, and premium analytics. I need to remember that float-sharing isn't an immediate part of the plan and might need to stay structured through partnerships later.
-
-Oh, and commission advances backed by employers are mentioned for the future after gathering reliable data; there's a time frame for Brazil, but it won't launch early.
-
-_Thinking:_
-
-**Exploring regulatory concerns**
-
-I’m considering how some strategies might raise regulatory or custody issues, especially in relation to partner-led custody. I should avoid leading with float or holding customer cash. It seems important to focus on balancing retention incentives tied to actual usage rather than making explicit interest promises in the roadmap.
-
-Also, discounted rates based on retained balances might not be clearly defined and could be risky. I'm looking into card issuance, refund rate forecasts, and potential payout delays based on available reserves.
-
-_Thinking:_
-
-**Exploring business model details**
-
-I'm looking into how interest and fees relate to employers. It seems there's potential for sharing fees with employers to provide incentives, but it's not explicitly mentioned in the documents. There's also talk of employer-backed advances and revenue, although revenue-sharing isn't clear.
-
-The idea of setting limits for payout rules is implied but not explicitly stated. I might consider changing the marketing wording to clarify how payments and commissions are handled. There's a chance to revise how we frame the monetization of system friction as well.
-
-_Thinking:_
-
-**Clarifying user inquiry**
-
-The user is asking if there are any aspects in the plan that we've missed. My best response, I think, is that while most points are covered, some specific additions are new or not fully developed, and a few ideas might conflict with the current plan.
-
-I should provide quotes from the documents, using file references and line numbers for clarity. It might not be necessary to inspect every line since we have those numbers already, but referencing relevant sections would enhance precision. For example, citing paths like `docs/01-core-idea.md:71` could be helpful.
-
-_Thinking:_
-
-**Ensuring accuracy in documentation**
-
-To ensure precision, I can check the line numbers again, which I already have access to. It seems like utilizing standalone path references would be the best way to cite sections, such as `docs/01-core-idea.md:71`. There's no need to provide a range for these references. Additionally, I should consider updating the to-do list statuses as part of this process. That way, everything stays organized and clear for future reference!
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Read the key planning docs to understand current scope and assumptions",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Compare the user's conversation notes against the documented plan",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Report what is already covered versus new or underexplored ideas",
- "status": "completed",
- "priority": "high"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Read the key planning docs to understand current scope and assumptions",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Compare the user's conversation notes against the documented plan",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Report what is already covered versus new or underexplored ideas",
- "status": "completed",
- "priority": "high"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 103.0s)
-
-_Thinking:_
-
-**Exploring pricing strategies**
-
-I’m considering offering discounted rates to companies that keep a certain amount with us. This could encourage them to build up their reserves, helping us initiate a lending aspect in the business. However, the current documents suggest focusing on employer-backed advances later. I should also think about how sharing fees with employers might not have been discussed. This could be a new pricing idea, but it needs regulatory review since we're currently avoiding early lending. The card system setup by partners is already covered.
-
-_Thinking:_
-
-**Reviewing refund and cancellation policies**
-
-I'm thinking about how we should handle refunds and cancellations. Once we have enough data on refund rates, we'll need that reversal data for risk assessment. Initially, we could partially pay out or indicate that funds will be accessible in a few days. The UX around displaying earned amounts and withdrawals isn’t fully explored yet. If employers know the refund frequency, we could structure shared economics, but that’s not in the plan. I'll also adjust messaging to avoid emphasizing profit from system friction.
-
-_Thinking:_
-
-**Updating documentation features**
-
-I'm thinking about what to add to the documentation. Some ideas include explicit features like employer-side filtering, employee target progress tracking, and a refund-rate dashboard. I want to mention advanced analytics for monetization, including performance-drop alerts. Also, employer-defined limits on early access to advances could be relevant, as well as revenue-sharing on advance fees and volume-based pricing discounts.
-
-I'm noticing a tension with the current plan regarding fund custody and the reliance on early advances. I should also clarify the focus on employee liquidity rather than instant crediting to employer accounts.
-
-_Thinking:_
-
-**Addressing refund and cancellation handling**
-
-I need to mention that refund and cancellation handling are under consideration, but some operational decisions remain undocumented. This includes payout timing policies based on employer verticals, reserve sizing methodologies, and the design of employer-funded or clawback agreements. Also, I should clarify UI wording for pending versus available funds and identify who bears losses when an employee exits after a payout. It would be good to check for any gaps in our discussions and suggest additions to the plan documents.
-
-_Thinking:_
-
-**Evaluating project notes**
-
-I'm considering the notes I've reviewed, and I would say, in short, they mostly reinforce the current plan. There are a few new details or explicit items that aren't yet addressed, and some points conflict with the established guidelines.
-
-I’ve noted already covered aspects, like B2B2C positioning and payment-linked commissions. However, there are new and underexplored ideas, including employee target tracking and refund-rate analytics.
-
-A few conflicts arise too, such as how to handle funds and the timing of advances. Let’s clarify these.
-
-_Thinking:_
-
-**Refining notes and recommendations**
-
-I’m thinking of how to mark the notes, perhaps as "not really new but sharper phrasing." They don't introduce a radically different strategy; rather, they add product and pricing details.
-
-I could highlight three valuable items to incorporate: 1) employer-configurable availability policies, 2) explicit analytics roadmap, and 3) advance-economics design. Maybe I can offer to update the documents since I wasn't asked to edit.
-
-I should suggest options like creating a gap list for the docs, updating the roadmap, or rewriting the refund policy section. I'll ensure my language is careful so as not to overstate what's been discussed.
-
-_Thinking:_
-
-**Assessing dashboard elements**
-
-I'm noticing that performance drop alerts are quite close to what’s needed. However, the phrase "progress towards targets" isn’t explicit in the current setup.
-
-Also, while the ability to filter transaction history by employee and time period feels somewhat implied, it doesn’t seem to be clearly laid out either.
-
-I should consider how to better articulate these points to ensure clarity in what should be included in the documentation or dashboard.
-
-_Thinking:_
-
-**Considering float-sharing economics**
-
-I’m thinking about the float-sharing or treasury economics and how it might relate to our partner structure. It seems early float isn't part of the plan, and I should focus on avoiding float economics in the documents. I might mention that a key feature is instant crediting of payments to both employers and employees, but I’m unsure if emphasizing same-day employer balance is necessary. Maybe I can create a concise table with bullets, with headers like `Verdict` to keep it organized.
-
-_Thinking:_
-
-**Evaluating notes consistency**
-
-I'm considering whether the notes align with the plan. Mostly, they do, but a few details are either not clear or contradict the current thesis. I'll need some bullet points with supporting citations for clarity. For example, I should cover areas like the platform's role between payment and payout, partner custody, and analytics. There are also new elements like employer-configurable payout policies that need to be highlighted. I think adding explicit details about employee tracking could enhance clarity too.
-
-_Thinking:_
-
-**Considering next steps**
-
-I need to think about natural next steps to suggest. If the user wants, I could: 1. create a document gap list, 2. update the roadmap with missing items, or 3. draft a refund/availability policy. Since there are no code edits, these options seem doable. I should avoid unsupported claims, like percentages that might not be accurate. Instead, I can say it's "mostly covered." I want to keep a friendly tone and highlight which areas need focus. Let’s analyze everything thoroughly!
-
-_Thinking:_
-
-**Evaluating financing strategies**
-
-I see that I’ve built some reserves, and the current plan suggests implementing risk-based credit later when reliable data is available. It seems like reserve capitalization for advances and lending might need more exploration, though it could be outside the initial plan due to guardrails. There’s mention of discounted rates for larger amounts, which isn’t documented yet. Also, while basic analytics are covered in the current version, some elements like projections and performance alerts require clarification.
-
-_Thinking:_
-
-**Clarifying payment processes**
-
-I could note that "instant crediting of payments" implies both employers and employees have subledgers, which is mentioned in the docs regarding their balances. The use of payment processors like Stripe or Adyen is also explicitly referenced in the documentation. Additionally, phrases like "partially pay it out" and "take it out in X days" map to specific states but could benefit from clearer UI documentation about withdrawal dates. While the marketing language should avoid terms like "payday loan," the idea of leveraging system friction for profit isn’t advisable.
-
-_Thinking:_
-
-**Assessing friction management**
-
-I could mention that the current plan sees friction as a risk rather than an opportunity for profit. It might be worth noting that allowing companies to set limits is not just about policy configuration but is important. I could propose adding this to the documentation. Also, I can categorize what's been discussed into three buckets: covered, need to add, and rethink. There are other important considerations, like employee termination risks, employer reserve mechanics, and service-level commitments, which aren't explicitly covered but are worth mentioning.
-
-_Thinking:_
-
-**Considering policy configuration**
-
-The roadmap hints at policy configuration but doesn’t clearly state that employers can set limits on a per-team, per-user, or per-scenario basis. It’s also noted that employee target tracking and employer refund-rate analytics are mentioned, but the current documentation doesn’t specify those views precisely. There’s talk about premium analytics productization, yet it would be helpful if specific alert types, like "rep drop in performance,” were made more explicit.
-
-_Thinking:_
-
-**Exploring payment nuances**
-
-I should consider the underexplored nuances regarding instant payment crediting. My friend has mentioned how payments are credited to employers' and employees' accounts, but the docs indicate that while balances are allocated immediately, cash settlement for employers occurs on a defined schedule. This could clarify potential conflicts; I should point out that “immediate employer cash access” isn’t promised and should be careful with terms like "accounts." Using "subledgers" might be more accurate. The user texts are based on conversations and shared documents.
-
-_Thinking:_
-
-**Evaluating discussion points**
-
-I need to check if there are any aspects we've overlooked in our plan. It might be helpful to say, “A few things aren’t explicitly mentioned in the plan.” This could serve as a prompt to ensure all bases are covered. I want to make sure I don't miss anything important, so I'll carefully review our earlier discussions to identify any gaps. It's always good to be thorough and clarify any uncertainties!
-
-_Thinking:_
-
-**Considering final answer structure**
-
-I'm thinking about how to manage the context for the conversation since it’s short. No compression is needed, and I don't need to use any tools right now. I want to craft a final answer that’s concise yet detailed enough.
-
-I'll structure it with clear headers and bullet points—highlighting what's already covered, new or underexplored points, corrections, and next steps. I’ll ensure the first bullet isn’t left blank. It’s all about being precise with the content and citations.
-
-_Thinking:_
-
-**Reviewing key points**
-
-I’m assessing the core model that connects customer payment, employers, and employees, which is already documented in the core idea. I think I can cite relevant lines but shouldn’t over-cite every bullet. For example, I can mention “refund-rate analytics” in a less explicit way, acknowledging the risks like refunds and chargebacks without calling it out as a main metric.
-
-I can also highlight other aspects like employee tracking, volume discounts, and company limits, which are implied but not clearly documented. Overall, it seems that the conversations align well with the current plan.
-
-_Thinking:_
-
-**Considering product roadmap**
-
-I'm looking into how making advances is mentioned as a potential feature but seems to be planned for after the core ledger and payout loop are proven. It's an interesting strategic decision, and I wonder how it impacts the development timeline. It feels like a cautious approach to ensure the foundational elements are solid before adding new features like advances, which could be valuable later on. It's all about finding the right balance!
-
-_Thinking:_
-
-**Considering analytics and pricing**
-
-I'm thinking about the explicit analytics features needed, like tracking refund rates, target progress, and performance-drop alerts. Also, I need to consider the pricing and economic design for employer-backed advances.
-
-If the user wants, I could transform this into a concrete document gap list or draft a section covering refunds and availability policies. It's essential to provide relevant details here to help clarify the concepts involved!
-
-Mostly yes: these notes are largely aligned with the current plan. The genuinely new bits are mostly product/pricing details; the main things I would not carry forward are direct custody, early float dependence, and early lending.
-
-**Already Covered**
-- The core model of sitting between customer payment, employer, and employee is already central in `docs/01-core-idea.md:24`.
-- Using payment/BaaS partners, including `Stripe BR`, `Adyen`, and separate card-issuance providers, is already contemplated in `docs/02-brazil-market.md:101` and `docs/02-brazil-market.md:105`.
-- Basic employer/employee dashboards now, richer analytics later, are already in scope in `docs/02-brazil-market.md:73`, `docs/01-core-idea.md:60`, and `docs/05-roadmap-12-months.md:100`.
-- Refund/cancellation handling via holdbacks, reserves, partial availability, and delayed access is already baked in at `docs/01-core-idea.md:170`, `docs/02-brazil-market.md:137`, and `docs/05-roadmap-12-months.md:33`.
-- Employer-backed advances are already in the plan, but intentionally later and tightly controlled in `docs/01-core-idea.md:66` and `docs/05-roadmap-12-months.md:151`.
-
-**New Or Not Explicit Yet**
-- Employer-configurable limits on what becomes available, and when; the roadmap mentions policy config, but not this as a clear product control in `docs/05-roadmap-12-months.md:104`.
-- Specific analytics modules like employee target progress, refund-rate reporting, and “rep performance dropped” alerts; current docs are close, but not that explicit. The nearest item is anomaly alerts in `docs/05-roadmap-12-months.md:103`.
-- Sharing advance fees/interest with the employer is new; the docs discuss employer-backed advances, but not revenue-sharing mechanics.
-- Volume-based discounts or pricing tiers for employers are not documented yet.
-- The exact UX of “earned now, withdrawable in X days” is implied by `earned` / `available` / `settled`, but not written out as a user-facing rule.
-
-**Conflicts With The Current Thesis**
-- “Money goes to our account” conflicts with the current partner-held-custody model and the guardrail against direct custody early in `docs/01-core-idea.md:73` and `docs/02-brazil-market.md:126`.
-- “Float as early revenue” conflicts with the current sequencing, which starts with software and movement fees and only treats float-sharing as a later possibility in `docs/01-core-idea.md:114`, `docs/01-core-idea.md:121`, and `docs/04-positioning-and-landing-copy.md:70`.
-- Using retained funds to build a lending business early is not in the plan and would pull you into regulatory and balance-sheet risk too soon.
-- Making advances an early core feature is directionally discussed, but the roadmap deliberately keeps them after the core ledger + payout loop is proven in `docs/05-roadmap-12-months.md:173`.
-
-The biggest useful additions to fold into the docs are:
-1. explicit employer-set availability/limit controls
-2. explicit analytics features: refund rate, target progress, performance-drop alerts
-3. pricing/economic design for employer-backed advances
-
-If you want, I can turn this into a concrete doc gap list or draft the missing refund/availability-policy section.
-
----
-
-## User
-
-add whatever is not included in the docs to a separate file, so I can review it later. Also, add a README to the repo, to work as an index for the documents
-
----
-
-## Assistant (Build · gpt-5.4 · 9.5s)
-
-_Thinking:_
-
-**Organizing documentation files**
-
-I need to respond to the user’s request to compile anything not included in the documentation into a separate file for later review, plus add a README to the repository. First, I’ll inspect the repo structure, maybe check the docs directory and see if a README already exists. Since this is multi-step and requires some checks, I’ll use specialized tools to examine the top-level directory and create the necessary files.
-
-_Thinking:_
-
-**Exploring documentation updates**
-
-I’m thinking about including new ideas that aren’t documented yet, and I might also want to list any conflicts or intentionally excluded topics. I’ll create a file to outline underexplored or new ideas from the conversation for future review, possibly titled "Ideas to Review." Since the user wants these preserved neutrally, I could note any tensions with the current thesis. I’ll also need to make a README index summarizing the documentation files after inspecting the repo for existing content. Let's start with the necessary checks!
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Inspect repository structure and confirm whether a README already exists",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Draft a review file with ideas from the conversation not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the main documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify the new files and summarize what was added",
- "status": "pending",
- "priority": "medium"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Inspect repository structure and confirm whether a README already exists",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Draft a review file with ideas from the conversation not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the main documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify the new files and summarize what was added",
- "status": "pending",
- "priority": "medium"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 6.4s)
-
-_Thinking:_
-
-**Planning file edits**
-
-I need to respond to the user by editing files, so I'll start by inspecting the repository structure and checking for a README file. It seems likely that I should create a separate file for any uncovered ideas and also develop a README index. I want to use appropriate tools like read and glob for file operations instead of bash. I'll also need to check the repo's root directory for structure and potentially use glob for README files. Using parallel tasks might be helpful here too.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll
-directory
-
-.git/
-AGENTS.md
-docs/
-sessions/
-
-(4 entries)
-
-```
-
-**Tool: glob**
-
-**Input:**
-```json
-{
- "pattern": "README*",
- "path": "/home/alex/projects/payroll"
-}
-```
-
-**Output:**
-```
-No files found
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs
-directory
-
-01-core-idea.md
-02-brazil-market.md
-03-market-memo.md
-04-positioning-and-landing-copy.md
-05-roadmap-12-months.md
-
-(5 entries)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 17.8s)
-
-_Thinking:_
-
-**Preparing document files**
-
-I'm getting ready to respond to the user's request by editing files. I need to create a separate file for items not included in the earlier analysis and prepare a README that indexes these documents. I might consider existing styles and decide on sensible file names. It seems like putting everything under the `docs` folder is a good approach. I should also clarify any notes on unendorsed items and ensure the README lists the documents and provides an overview.
-
-_Thinking:_
-
-**Deciding on document modifications**
-
-I’m thinking about how I might not need to modify any existing document content, except if the README needs to reference a new file. It could be helpful to verify changes by reading the new files after patching. I need to make sure I don’t override any changes made by the user. Compressing the range from m0001 to m0004 seems like a steady housekeeping move. It's probably best to do this for closed interactions while being cautious about not affecting current user requests. Let's proceed with the compression!
-
-**Tool: compress**
-
-**Input:**
-```json
-{
- "topic": "Idea Gap Review",
- "content": {
- "startId": "m0001",
- "endId": "m0004",
- "summary": "The user asked whether two quoted conversation snippets with a friend contained ideas not yet discussed or considered in the repo plan. The first snippet proposed a model where the company sits between customer, company, and employee; handles payments via BaaS plus providers like Stripe or Adyen; instantly credits employers and employees; offers analytics to companies and staff from the start; may sell advanced analytics as an extra service; initially monetizes through a percentage of processed payments plus float; could offer employer-backed commission advances early, sharing fees or interest with employers; could use discounted rates to incentivize companies to keep money on-platform; and could later add cards through external card-as-a-service providers. The second snippet focused on refunds/cancellations and suggested using data on refund rates, partial payouts or delayed withdrawal windows, employer-backed advances, employer-set limits, possible changes to marketing wording, and monetizing friction from the refund/advance dynamic.\n\nTo answer, the repo docs were reviewed in full: `docs/01-core-idea.md`, `docs/02-brazil-market.md`, `docs/03-market-memo.md`, `docs/04-positioning-and-landing-copy.md`, and `docs/05-roadmap-12-months.md`.\n\nKey findings from the comparison:\n- Already covered in the docs: the core model of sitting between customer payments, employer, and employee; use of payment/BaaS partners and examples like `Stripe BR`, `Adyen`, and separate card issuance partners; basic dashboards now and richer analytics later; refund/cancellation handling through reserves, holdbacks, partial availability, and delayed access; and employer-backed advances as a later, tightly controlled feature.\n- New or not explicit enough in the current docs: employer-configurable rules for how much commission becomes available and when; more specific analytics modules such as employee target progress, refund-rate reporting, and alerts when employee performance drops; sharing advance fees/interest with the employer; volume-based discounts or pricing tiers for employers; and the explicit user-facing UX/message of “earned now, withdrawable in X days,” which is implied by the `earned`/`available`/`settled` model but not described directly.\n- In tension or conflict with the current thesis: direct custody phrased as “money goes to our account,” which conflicts with the documented partner-held custody model; early float as a core revenue source, which conflicts with the planned sequencing that starts from software and money-movement economics and treats float-sharing as later/conditional; using retained funds to build lending early, which would add regulatory and balance-sheet risk too soon; and making advances an early core feature, which conflicts with the roadmap sequencing that keeps advances after the core ledger and payout loop is proven.\n\nThe final response told the user that most of the conversation ideas were already reflected in the docs, highlighted the genuinely new items above, called out the conflict areas that should not be carried forward as-is, and recommended three especially useful additions to capture somewhere later: explicit employer-set availability/limit controls, explicit analytics features like refund rate / target progress / performance-drop alerts, and pricing/economic design for employer-backed advances. The assistant then offered to turn this into a concrete doc gap list or draft a missing refund/availability policy section."
- }
-}
-```
-
-**Output:**
-```
-Compressed 4 messages into [Compressed conversation section].
-```
-
----
-
-## User
-
-▣ DCP | ~10.3K tokens saved total
-
-│⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿████████████████████████████│
-▣ Compression #1 (~10.3K tokens removed, 42% reduction)
-→ Topic: Idea Gap Review
-→ Items: 4 messages and 7 tools compressed
-
----
-
-## Assistant (Build · gpt-5.4 · 12.0s)
-
-_Thinking:_
-
-**Planning file edits**
-
-I need to respond to the user's request by editing files. First, I'll inspect the documentation for context, but I think I've got enough info already. I should create a separate file for ideas not included and possibly a README index.
-
-It seems I might need to check the style guide as well. Based on the user's suggestion, I'll create a file, likely under docs, titled `docs/06-additional-ideas-for-review.md`, to note whatever's missing. I’ll also consider how to reference conflict items.
-
-_Thinking:_
-
-**Organizing undocumented ideas**
-
-The user asks me to add anything not included in the docs to a separate file for later review. This means I should include not only new ideas but also any that might create tension. I'll likely create a file titled `docs/06-additional-ideas-for-review.md`, containing "High-value additions" and "Needs validation/conflicts."
-
-My plan is to keep modifications minimal, only adjusting the README to serve as an index, summarizing purpose and language. I'll check the titles and brief descriptions of existing files to ensure alignment.
-
-_Thinking:_
-
-**Reading document titles**
-
-I need to use the read tool on the documentation, likely looking at the first 30 lines of each in parallel. I should check the top lines of the docs. This will help me gather accurate titles and themes. While inspecting sessions might not be necessary, I think it’s good to focus on creating a solid overview based on those initial lines. This way, I can ensure I capture the key ideas effectively.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/01-core-idea.md",
- "offset": 1,
- "limit": 60
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/01-core-idea.md
-file
-1: # Core Idea
-2:
-3: ## One-line thesis
-4:
-5: A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.
-6:
-7: ## The problem
-8:
-9: ### Employers
-10:
-11: - Commission calculation is often manual, delayed, and hard to audit.
-12: - Sales teams ask for informal advances when payroll cycles lag behind real sales activity.
-13: - Finance teams struggle to forecast commission liability and reconcile payouts.
-14: - Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.
-15:
-16: ### Employees
-17:
-18: - A sale can happen today, but the commission may not be usable for days or weeks.
-19: - Early access to money often depends on asking for an informal advance.
-20: - There is rarely a clear view of what has been earned, what is available, and what is still pending.
-21:
-22: ## The product
-23:
-24: The product sits between customer payment collection and employer payout.
-25:
-26: 1. A customer makes a payment.
-27: 2. The platform receives the payment event directly, or receives trusted payment data from a partner.
-28: 3. A commission engine applies employer-defined rules.
-29: 4. The internal ledger allocates balances between employer and employee.
-30: 5. A safe portion of the employee's commission becomes available immediately.
-31: 6. The employee can cash out instantly, and later can also spend from a wallet or card.
-32: 7. The employer gets the remaining balance on a defined settlement schedule.
-33: 8. Both sides get visibility into earnings, payouts, and performance.
-34:
-35: ## Core product layers
-36:
-37: ### 1. Payment collection or orchestration
-38:
-39: - Accept customer payments directly, or integrate with the employer's processor.
-40: - Use payment events as the source of truth for commission creation.
-41:
-42: ### 2. Commission rules engine
-43:
-44: - Support percentage-based, tiered, and custom rules.
-45: - Lock an auditable calculation for every sale or payment event.
-46: - Track exceptions, reversals, and dispute states.
-47:
-48: ### 3. Ledger and balances
-49:
-50: - Maintain an internal double-entry ledger.
-51: - Track at least three states: `earned`, `available`, `settled`.
-52: - Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.
-53:
-54: ### 4. Instant access rails
-55:
-56: - Phase 1: instant bank transfer or `Pix` cash-out.
-57: - Phase 2: stored balance inside the app.
-58: - Phase 3: prepaid or debit card linked to the balance.
-59:
-60: ### 5. Employer analytics
-
-(Showing lines 1-60 of 197. Use offset=61 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/02-brazil-market.md",
- "offset": 1,
- "limit": 60
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/02-brazil-market.md
-file
-1: # Tese para o mercado brasileiro
-2:
-3: ## Resumo
-4:
-5: A melhor entrada para esta ideia no Brasil e uma plataforma B2B2C que conecta recebimento, calculo de comissao, ledger interno e acesso instantaneo ao saldo via `Pix`.
-6:
-7: O produto inicial nao deve ser vendido como banco digital nem como credito ao consumidor. A tese mais forte e:
-8:
-9: `transformar cada venda validada em saldo de comissao disponivel quase em tempo real`
-10:
-11: ## Por que o Brasil primeiro
-12:
-13: - `Pix` ja criou expectativa de movimentacao instantanea e barata.
-14: - O mercado convive com atraso no pagamento de comissoes e com o uso informal de `vales`.
-15: - Existem instituicoes financeiras, cooperativas, BaaS e emissores abertos a parcerias.
-16: - Ha muitos segmentos com equipes comerciais comissionadas e operacao digital crescente.
-17: - O argumento de valor e simples: menos atraso, menos friccao operacional e mais retencao do time de vendas.
-18:
-19: ## Dor local que o produto resolve
-20:
-21: ### Para a empresa
-22:
-23: - Calculo manual de comissao.
-24: - Fechamento mensal demorado.
-25: - Falta de visibilidade sobre passivo de comissao.
-26: - Uso informal de `vales`, com pouca governanca.
-27: - Dificuldade para reconciliar recebimento, comissao, estorno e repasse final.
-28:
-29: ### Para o vendedor
-30:
-31: - Venda feita hoje, dinheiro disponivel so dias ou semanas depois.
-32: - Dependencia de `vale` para cobrir caixa pessoal.
-33: - Falta de transparencia sobre o que foi ganho, o que esta disponivel e o que ainda esta pendente.
-34:
-35: ## ICP inicial
-36:
-37: O foco deve ser empresas brasileiras com time comercial comissionado e recebimento digital identificavel.
-38:
-39: Segmentos promissores:
-40:
-41: - franquias e operacoes de varejo com vendedores comissionados
-42: - clinicas de estetica, odontologia e procedimentos eletivos
-43: - academias e servicos recorrentes com equipe de vendas
-44: - escolas, cursos e educacao privada com captacao comercial
-45: - telecom, distribuicao e revendas com metas e bonificacao variavel
-46:
-47: ## Proposta de valor no Brasil
-48:
-49: ### Para a empresa
-50:
-51: - Automatizar o calculo e o repasse de comissoes.
-52: - Reduzir dependencia de `vales` informais.
-53: - Melhorar retencao e motivacao do time.
-54: - Ter visao confiavel de performance comercial e custo de comissao.
-55: - Ganhar previsibilidade de caixa e de passivo.
-56:
-57: ### Para o colaborador
-58:
-59: - Ver a comissao quase em tempo real.
-60: - Sacar instantaneamente via `Pix` quando o saldo estiver disponivel.
-
-(Showing lines 1-60 of 191. Use offset=61 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/03-market-memo.md",
- "offset": 1,
- "limit": 60
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/03-market-memo.md
-file
-1: # Market Memo
-2:
-3: ## Thesis
-4:
-5: There is a clear product gap between commission software, faster worker payouts, and Brazil-native embedded finance.
-6:
-7: Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a Brazil-first platform built around real-time commission availability.
-8:
-9: ## The gap in the market
-10:
-11: Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and informal employee advances. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
-12:
-13: Existing vendors tend to split into separate categories:
-14:
-15: - faster pay or earned wage access
-16: - payout rails and disbursement infrastructure
-17: - commission calculation and analytics software
-18: - employee wallet or card experiences
-19: - Brazil payment and card infrastructure
-20:
-21: The opportunity is to combine these into a single workflow built around a verified payment event.
-22:
-23: ## Competitor map
-24:
-25: | Company | What it does well | Missing piece relative to this idea |
-26: |---|---|---|
-27: | `DailyPay` | Earned wage access, employee liquidity, employer integrations | Not centered on payment-linked commissions or commission-heavy teams |
-28: | `Branch` | Workforce payments, employee app, card, embedded finance | More generic worker finance than commission-specific infrastructure |
-29: | `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system and Brazil-specific positioning |
-30: | `Hyperwallet` | Global payout orchestration | Infrastructure layer, not a commission system of record |
-31: | `CaptivateIQ` | Commission calculation, visibility, forecasting | No native money movement or worker access to balances |
-32: | `Caju` | Brazil employee finance and card experience | Not the source of truth for commission creation and payout logic |
-33: | `Dock` | Brazil financial infrastructure for accounts, cards, `Pix` | Not a direct competitor; more likely an enabling layer |
-34:
-35: ## What is differentiated here
-36:
-37: The strongest version of this company is not just a wallet and not just an analytics tool.
-38:
-39: It is:
-40:
-41: `a commission ledger that turns verified sales into immediately usable balances`
-42:
-43: That positioning changes the product in important ways:
-44:
-45: - the source of truth is a payment event, not a later payroll export
-46: - the employer gets workflow, controls, and analytics
-47: - the employee gets liquidity without relying on informal advances
-48: - the company can monetize software, payment flow, and later retained balances
-49:
-50: ## Why Brazil first
-51:
-52: Brazil is the more compelling launch market than Switzerland for this specific thesis.
-53:
-54: - `Pix` makes instant access behaviorally normal.
-55: - Informal paycheck advances or `vales` create a visible pain point.
-56: - Smaller financial institutions and infrastructure partners may be more open to collaboration.
-57: - Commission-heavy SMB and mid-market businesses are common.
-58: - The value proposition is concrete and easy to explain.
-59:
-60: Switzerland may still matter later, but Brazil provides the clearer wedge, larger behavioral advantage, and stronger infrastructure fit for instant commission access.
-
-(Showing lines 1-60 of 168. Use offset=61 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md",
- "offset": 1,
- "limit": 60
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md
-file
-1: # Positioning and Landing Copy
-2:
-3: ## Core positioning
-4:
-5: This company should not present itself as a generic earned wage access app.
-6:
-7: The stronger frame is:
-8:
-9: `commission infrastructure for real-time sales teams`
-10:
-11: ## Category statement
-12:
-13: We help employers turn verified sales into instantly accessible commission balances, with employer controls, worker payouts, and performance visibility built into one system.
-14:
-15: ## Short positioning line
-16:
-17: Turn every sale into an instantly usable commission balance.
-18:
-19: ## Headline options
-20:
-21: 1. Turn every sale into an instantly accessible commission.
-22: 2. Give sales teams instant access to earned commissions.
-23: 3. Real-time commissions for modern sales teams.
-24: 4. The fastest way to move from customer payment to salesperson payout.
-25: 5. Commission payouts, employer controls, and worker access in one platform.
-26:
-27: ## Subhead options
-28:
-29: 1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.
-30: 2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.
-31: 3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.
-32:
-33: ## Product pillar copy
-34:
-35: ### Real-time commission engine
-36:
-37: Calculate commissions from verified payment events instead of waiting for payroll cycles and spreadsheet reconciliations.
-38:
-39: ### Instant worker access
-40:
-41: Give employees access to eligible commission balances right away, starting with instant cash-out and later expanding to wallet and card spend.
-42:
-43: ### Employer control and auditability
-44:
-45: Set payout rules, track reserve logic, and keep a reliable audit trail across every sale, split, payout, and adjustment.
-46:
-47: ### Payment-linked performance data
-48:
-49: See team performance, commission liability, and payout trends from real money movement rather than disconnected reporting tools.
-50:
-51: ## Employer value props
-52:
-53: - Reduce manual commission operations.
-54: - Replace informal advances with a controlled workflow.
-55: - Improve salesperson retention and motivation.
-56: - Get a clearer view of commission cost and team performance.
-57: - Create a better employee experience without building internal fintech operations.
-58:
-59: ## Employee value props
-60:
-
-(Showing lines 1-60 of 134. Use offset=61 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/05-roadmap-12-months.md",
- "offset": 1,
- "limit": 60
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md
-file
-1: # 12-Month Roadmap
-2:
-3: ## Guiding principle
-4:
-5: Do not start by building a broad neobank or a consumer lending app.
-6:
-7: Start with the smallest product that proves the core wedge:
-8:
-9: `payment-linked commission calculation plus instant access to earned balances`
-10:
-11: ## Success goal for year one
-12:
-13: By the end of 12 months, the company should prove that employers will adopt a commission-led payout workflow and that employees will use it for faster access to earnings.
-14:
-15: The year-one target is not maximum feature breadth. It is proof of product-market fit for the core loop.
-16:
-17: ## Phase 0: Foundation and partner design
-18:
-19: ### Months 0-2
-20:
-21: #### Objectives
-22:
-23: - validate the first customer segment
-24: - choose partner model for custody, payouts, and compliance
-25: - lock the ledger and commission system design
-26:
-27: #### Workstreams
-28:
-29: - run design-partner interviews with target employers
-30: - map employer commission workflows and exception cases
-31: - choose payment and banking partner shortlist
-32: - define balance states: `earned`, `available`, `settled`
-33: - define reserve and holdback logic for reversals
-34: - specify onboarding flows for employers and employees
-35:
-36: #### Deliverables
-37:
-38: - product requirements for v1
-39: - legal and regulatory issue map
-40: - partner shortlist and integration plan
-41: - event model for payments, commissions, adjustments, and payouts
-42:
-43: #### Exit criteria
-44:
-45: - 5 to 10 serious design partners in pipeline
-46: - clear v1 scope that does not depend on lending
-47: - chosen path for `Pix` and custody infrastructure
-48:
-49: ## Phase 1: Core ledger and instant payout access
-50:
-51: ### Months 2-5
-52:
-53: #### Objectives
-54:
-55: - launch the first working employer flow
-56: - prove that a verified sale can become an eligible commission balance
-57: - enable instant cash-out for employees
-58:
-59: #### Product scope
-60:
-
-(Showing lines 1-60 of 185. Use offset=61 to continue.)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 14.1s)
-
-_Thinking:_
-
-**Preparing user documentation**
-
-I need to respond to the user's request by working on the documentation. First, I’ll add a separate file for ideas that aren’t included and create a README index. I’ll check the docs structure to see if there's more content to reference, possibly including session details.
-
-I'll name the files something like `README.md` and `docs/06-additional-ideas-to-review.md`. The separate file should contain only the ideas requested without conflicting with the existing content, possibly divided into sections like "Potential additions" and "Ideas not recommended as-is."
-
-_Thinking:_
-
-**Creating user documentation files**
-
-I need to follow the instruction to add items not included in the docs to a separate file. It makes sense to include both new ideas and any conflicting or out-of-scope items, labeling them "not recommended / in tension" for review later. I should review the documentation to create a solid README index, possibly summarizing each document with one-liners.
-
-I might need to create files using either `apply_patch` or `write`, and check if the README file is missing, which I could place in the repo root. I’ll also consider including sections on "How to use this repo" and a "Document map."
-
-_Thinking:_
-
-**Structuring documentation and files**
-
-I might also need to include a note about a "documentation-first workspace" since the repo will primarily contain docs. The README should work as an index, covering the current thesis, documentation conventions, and suggested reading order. I should look into the `docs` summaries from AGENTS, particularly anything from line 60 onward, although that might not be strictly necessary.
-
-For the new review file, I can mention that these ideas stem from external conversations and aren't represented elsewhere. I need to maintain English as the default language. After reviewing, I’ll update the TODO status and create files using `apply_patch` for the new content.
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Inspect repository structure and confirm whether a README already exists",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Draft a review file with ideas from the conversation not yet captured in docs",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the main documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify the new files and summarize what was added",
- "status": "pending",
- "priority": "medium"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Inspect repository structure and confirm whether a README already exists",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Draft a review file with ideas from the conversation not yet captured in docs",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the main documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify the new files and summarize what was added",
- "status": "pending",
- "priority": "medium"
- }
-]
-```
-
----
-
-## User
-
-Also, drop the numbering in the docs
-
----
-
-## Assistant (Build · gpt-5.4 · 12.2s)
-
-_Thinking:_
-
-**Evaluating document numbering**
-
-I’m considering the AGENTS key docs and whether they reference numbered files. The user might want to remove numbering, so I need to think about adjusting internal link references as well. I'll inspect the entire repo for numbered document references using glob or grep since no README exists. It seems I might need to create a new file, possibly docs/gap-review.md or docs/open-ideas.md. If I drop numbering, AGENTS might need to reference new names to guide future agents.
-
-_Thinking:_
-
-**Planning document updates**
-
-I’m looking at the first 60 lines, and I’m not sure if that’s enough information. I might need to include more lines from each document, or maybe just the top descriptions will do. I’ll create a README and generate to-do updates for renaming docs and updating references using todowrite since I’m familiar with it. I’ll also plan to search for file references to numbered docs, rename them by removing prefixes, and create a separate review file for unaddressed ideas.
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "pending",
- "priority": "medium"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "pending",
- "priority": "medium"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 11.2s)
-
-_Thinking:_
-
-**Inspecting editing tools**
-
-I’m realizing that there’s no Edit/Write tool in the functions namespace. Instead, I should use apply_patch for file edits, and I can likely rename files using the bash mv command. Before that, I'll need to verify if the parent directories exist by using ls. I already have documentation to refer to, and I might utilize grep to search for references. I’m considering using multi_tool_use.parallel for grep patterns and globbing markdown files too. Let's take a closer look at the repository!
-
-**Tool: glob**
-
-**Input:**
-```json
-{
- "pattern": "**/*.md",
- "path": "/home/alex/projects/payroll"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/AGENTS.md
-/home/alex/projects/payroll/sessions/session-ses_2f39.md
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md
-/home/alex/projects/payroll/docs/03-market-memo.md
-/home/alex/projects/payroll/docs/02-brazil-market.md
-/home/alex/projects/payroll/docs/01-core-idea.md
-/home/alex/projects/payroll/sessions/session-ses_2fe5.md
-```
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "docs/0[1-5]-|01-core-idea\\.md|02-brazil-market\\.md|03-market-memo\\.md|04-positioning-and-landing-copy\\.md|05-roadmap-12-months\\.md",
- "path": "/home/alex/projects/payroll",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-Found 32 matches
-/home/alex/projects/payroll/AGENTS.md:
- Line 38: - `docs/01-core-idea.md` - canonical summary of the product and business model
- Line 39: - `docs/02-brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR
- Line 40: - `docs/03-market-memo.md` - competitor map, differentiation, and investor-style memo
- Line 41: - `docs/04-positioning-and-landing-copy.md` - messaging and homepage copy directions
- Line 42: - `docs/05-roadmap-12-months.md` - phased roadmap for the first year
- Line 47: - Keep `docs/02-brazil-market.md` in pt-BR.
-
-/home/alex/projects/payroll/sessions/session-ses_2f39.md:
- Line 6235: I should mention that no edits have been made, which is good. I’m considering using a heading like **Plan** to be more helpful. Maybe I could add sections like **Deliverables** and **Default Choices**, each with 4-6 concise bullet points. I'll make sure there are no nested bullets, and ensure each section remains clear. Also, the file references should be clickable, like `session-ses_2fe5.md` and `docs/01-core-idea.md`. That sounds solid!
- Line 6246: - `docs/01-core-idea.md` — the core parts of the idea: problem, solution, money flow, product layers, revenue model, phased expansion, key risks.
- Line 6247: - `docs/02-brazil-market.md` — Brazil-specific thesis: why Brazil first, `Pix`, `vales`, target verticals, partner types, local regulatory/operational constraints, GTM.
- Line 6248: - `docs/03-market-memo.md` — investor-style memo: market gap, competitor map, wedge, differentiation, why now, business model.
- Line 6249: - `docs/04-positioning-and-landing-copy.md` — sharper messaging: headline options, subheads, value props, employer/employee language, CTA copy.
- Line 6250: - `docs/05-roadmap-12-months.md` — phased roadmap: core ledger + `Pix`, analytics + stored balance, cards, then credit/scale.
- Line 6253: - Write `docs/01-core-idea.md` first so the rest share one consistent framing.
- Line 6254: - Derive `docs/02-brazil-market.md` and `docs/03-market-memo.md` from that foundation.
- Line 6255: - Use those to produce `docs/04-positioning-and-landing-copy.md`.
- Line 6256: - Finish with `docs/05-roadmap-12-months.md` so the roadmap reflects the finalized narrative.
- Line 6260: - Founder/investor tone for `docs/03-market-memo.md`, more operator/practical tone for `docs/02-brazil-market.md`.
- Line 6263: If you want, the one choice worth deciding before execution is whether `docs/02-brazil-market.md` should stay in English or be written in Portuguese; otherwise I’d proceed with the defaults above once write mode is available.
- Line 6428: I'm thinking about how to structure the documentation, organizing it with specific files like "01-core-idea.md" and "02-brazil-market.md." I want to make sure it’s solid but not too verbose. Maybe a docs index could be helpful but I’m not sure it’s necessary. I should probably create the "docs" directory first and then apply patches for the new files. The AGENTS.md should give context about the project, everything from its purpose to the target audience. I’ll need to ensure content is consistent throughout!
- Line 6657: I’m considering a multi-entity forecast for partner expansion with a potential employer-backed advance general release. I've outlined metrics like commission GMV, conversion rates, and payout latency, but I shouldn’t go beyond certain scopes, such as standalone consumer lending or full payroll. I might create `docs/01-core-idea.md` to avoid too much duplication while ensuring it serves as a clear internal summary. I need to include a clear money flow block in that document and keep it concise, around 700 lines. Let's build this carefully!
- Line 6664: "patchText": "*** Begin Patch\n*** Add File: /home/alex/projects/payroll/docs/01-core-idea.md\n+# Core Idea\n+\n+## One-line thesis\n+\n+A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.\n+\n+## The problem\n+\n+### Employers\n+\n+- Commission calculation is often manual, delayed, and hard to audit.\n+- Sales teams ask for informal advances when payroll cycles lag behind real sales activity.\n+- Finance teams struggle to forecast commission liability and reconcile payouts.\n+- Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.\n+\n+### Employees\n+\n+- A sale can happen today, but the commission may not be usable for days or weeks.\n+- Early access to money often depends on asking for an informal advance.\n+- There is rarely a clear view of what has been earned, what is available, and what is still pending.\n+\n+## The product\n+\n+The product sits between customer payment collection and employer payout.\n+\n+1. A customer makes a payment.\n+2. The platform receives the payment event directly, or receives trusted payment data from a partner.\n+3. A commission engine applies employer-defined rules.\n+4. The internal ledger allocates balances between employer and employee.\n+5. A safe portion of the employee's commission becomes available immediately.\n+6. The employee can cash out instantly, and later can also spend from a wallet or card.\n+7. The employer gets the remaining balance on a defined settlement schedule.\n+8. Both sides get visibility into earnings, payouts, and performance.\n+\n+## Core product layers\n+\n+### 1. Payment collection or orchestration\n+\n+- Accept customer payments directly, or integrate with the employer's processor.\n+- Use payment events as the source of truth for commission creation.\n+\n+### 2. Commission rules...
- Line 6671: A docs/01-core-idea.md
- Line 6672: A docs/02-brazil-market.md
- Line 6673: A docs/03-market-memo.md
- Line 6674: A docs/04-positioning-and-landing-copy.md
- Line 6675: A docs/05-roadmap-12-months.md
- Line 6697: - Added the core concept doc in `docs/01-core-idea.md`
- Line 6698: - Added the Brazil-specific thesis in pt-BR in `docs/02-brazil-market.md`
- Line 6699: - Added the investor-style market memo in `docs/03-market-memo.md`
- Line 6700: - Added positioning and landing copy in `docs/04-positioning-and-landing-copy.md`
- Line 6701: - Added the phased first-year plan in `docs/05-roadmap-12-months.md`
- Line 6716: 3. I can turn this into a simple landing page or pitch deck structure based on `docs/04-positioning-and-landing-copy.md`
-```
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "docs/0[1-5]-|01-core-idea\\.md|02-brazil-market\\.md|03-market-memo\\.md|04-positioning-and-landing-copy\\.md|05-roadmap-12-months\\.md",
- "path": "/home/alex/projects/payroll",
- "include": "AGENTS.md"
-}
-```
-
-**Output:**
-```
-Found 6 matches
-/home/alex/projects/payroll/AGENTS.md:
- Line 38: - `docs/01-core-idea.md` - canonical summary of the product and business model
- Line 39: - `docs/02-brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR
- Line 40: - `docs/03-market-memo.md` - competitor map, differentiation, and investor-style memo
- Line 41: - `docs/04-positioning-and-landing-copy.md` - messaging and homepage copy directions
- Line 42: - `docs/05-roadmap-12-months.md` - phased roadmap for the first year
- Line 47: - Keep `docs/02-brazil-market.md` in pt-BR.
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 27.4s)
-
-_Thinking:_
-
-**Considering repo modifications**
-
-I need to respond to the user's request and modify the repository. It seems I’ll likely use apply_patch and possibly bash mv for file operations. I'll have to inspect the files for references that need updates, like AGENTS and sessions. The user probably wants docs numbering dropped. Since sessions are transcripts, I may decide not to update them. I need to create a new README and another file, possibly something like docs/gap-review.md. I'll also consider updating AGENTS references to reflect any name changes.
-
-_Thinking:_
-
-**Deciding on document consistency**
-
-If I want the references in the repository to stay consistent, I might leave transcripts as historical records. The user asked to "drop the numbering in the docs," which likely means I need to rename files in the documentation and update active references. I could create a README index and maybe a separate file like `docs/review-later.md`. It's unclear if the user means file numbering or numbering within document headings. I need to inspect headings to see if numbered section headings exist.
-
-_Thinking:_
-
-**Interpreting numbering changes**
-
-The user requested to "drop the numbering in the docs," which could mean removing numbers from file names rather than content. However, it may also apply to headings like "1. Payment collection or orchestration." I need to interpret this broadly, focusing on removing numbering from filenames and organizational headings, while keeping meaningful sequences intact. For instance, I might update docs titles like `### 1. Payment collection or orchestration` to `### Payment collection or orchestration`. I should consider keeping numbering for essential roadmap phases since sequence might be important. I need to infer the best approach for this!
-
-_Thinking:_
-
-**Clarifying filename decisions**
-
-I think the user wants to drop numbering in filenames since they mentioned "also" when talking about adding a README for the repo as an index for the documents. It seems they might be referring to dropping numeric prefixes from the documents themselves, like those named `01-...`. I'll interpret that as a request for filenames and not alter any substantive numbered lists inside the documents. I should also think about including a section in the README about sessions and perhaps listing ideas for review in a separate file.
-
-_Thinking:_
-
-**Deciding on review file content**
-
-I’m thinking that `docs/review-later.md` fits well with the user’s request to "review it later." They mentioned including a list of gaps and conflicts, implying we should focus on missing ideas rather than conflicts. However, conflicts might be useful to note since they highlight items excluded for disagreement. The user wants a separate file for review, suggesting something like `docs/open-questions-and-additions.md` could work, possibly with sections for both potential additions and intentionally excluded ideas clearly labeled.
-
-_Thinking:_
-
-**Planning README structure**
-
-I need to think through the repo structure to check if there's a README file; if not, I’ll create `README.md` at the root. This file should serve as an index for the documents, possibly mentioning their new names after renaming. I want to include an overview of the repository, a doc index, a note on language, and a suggested reading order, perhaps using bullet points or sections without numbering. I might also include information about session transcripts.
-
-_Thinking:_
-
-**Updating documentation paths**
-
-I'm thinking about updating the AGENTS key documentation paths, possibly dropping the prefix in the file names. I'll also consider adding a separate file reference in the README while ensuring any cross-references within the docs are updated. It seems I should only focus on AGENTS since the session transcripts shouldn't be edited. I could also document that transcripts keep historical references. Lastly, I'll check my changes to confirm no other numbered references exist.
-
-_Thinking:_
-
-**Accessing documentation context**
-
-I’m considering whether I just need to read the top sections or if I need more context for the content in a separate file. I already have a summary, but I might need to check specific parts for accurate naming and references to concepts. Creating a separate file could help capture any missing ideas. I need to verify if the docs folder exists. The developer instructions suggest using specialized tools for file operations, which is good. I'll inspect the AGENTS lines for references next.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/AGENTS.md",
- "offset": 30,
- "limit": 30
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/AGENTS.md
-file
-30:
-31: ## Repository status
-32:
-33: - There is no production code yet.
-34: - The repo currently stores strategy and planning documents.
-35:
-36: ## Key documents
-37:
-38: - `docs/01-core-idea.md` - canonical summary of the product and business model
-39: - `docs/02-brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR
-40: - `docs/03-market-memo.md` - competitor map, differentiation, and investor-style memo
-41: - `docs/04-positioning-and-landing-copy.md` - messaging and homepage copy directions
-42: - `docs/05-roadmap-12-months.md` - phased roadmap for the first year
-43:
-44: ## Language conventions
-45:
-46: - Write in English by default.
-47: - Keep `docs/02-brazil-market.md` in pt-BR.
-48: - Keep fintech terminology consistent: `Pix`, `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.
-49:
-50: ## Transcripts
-51:
-52: - Transcripts of previous sessions are available under the sessions/ subdir, in case extra context is necessary.
-53:
-54: ## Product assumptions to preserve
-55:
-56: - Early architecture should rely on a licensed partner rather than direct custody.
-57: - The safest wedge is real-time access to earned commissions, not general lending.
-58: - The payment event is the source of truth for commission creation whenever possible.
-59: - The employer buyer needs controls, auditability, and analytics, not just a payout rail.
-
-(Showing lines 30-59 of 89. Use offset=60 to continue.)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 38.5s)
-
-_Thinking:_
-
-**Considering documentation updates**
-
-It sounds like I need to check the repository, especially since the user mentioned adding a README/index and possibly cleaning up filenames. When they said to "drop the numbering in the docs," I’m thinking it might refer to both filenames like `01-...` and the numbered headings in the documents. I should search for headings with numbers, like in `01-core-idea.md`. To meet their request, it might be best to address both filenames and numbered headings.
-
-_Thinking:_
-
-**Analyzing documentation updates**
-
-I’m realizing that modifying the content could be quite extensive. I need to inspect all documents for numbered headings and lists using a pattern search like `^#+ .*` to find any digits. While numbered bullet lists could also be legitimate, the user's request to "drop the numbering in the docs" might just mean removing numeric prefixes from file names. I'll need to rename documents accordingly and update the AGENTS, possibly the README and session files. However, I should probably leave the transcripts in sessions untouched since they are historical.
-
-_Thinking:_
-
-**Evaluating document formatting**
-
-I'm considering how to handle the user's request about numbering in documents. They mentioned wanting to remove the numbering from both headings and lists, and they’re concerned about filenames having numbers too. It's important to clarify if they want just the numbers dropped in content or everywhere. I think I could rename the files to remove numbers, and also change numeric headings and list markers to bullets, but I need to ensure that any sequences or rankings in lists remain clear. A question might be necessary!
-
-_Thinking:_
-
-**Finalizing document edits**
-
-I'll mention that I've removed numeric prefixes from filenames and updated the index, while retaining numbered sequences inside documents where they indicate order. If the user meant to include list or heading numbering, I can adjust those next. My developer suggests proceeding without prior approval unless there's a block. I think I’ll provide the default changes and clarify what would change with a different interpretation. Additionally, I could quickly search for numbered headings to decide their necessity. For file edits, I might apply a patch for single files, while renaming multiple files could use a bash `mv`.
-
-_Thinking:_
-
-**Exploring file operations**
-
-I see that we don't have a direct move or rename tool, but apply_patch can help move files to a new path. Renaming seems manageable using the bash `mv` command after verifying the parent directory exists, although it's noted that bash isn't for file operations. I think using apply_patch with specific commands could be a better approach for renaming files without changing their content. Lastly, I’ll remember to read the documentation carefully to ensure everything is correctly referenced.
-
-_Thinking:_
-
-**Considering file movement**
-
-I need to check if apply_patch can move files without altering their content. For example, using `*** Update File` and `*** Move to:` might work, but I'm unsure if it requires at least one hunk. I’m thinking that bash `mv` could be simpler, though we're advised against using bash for file operations. If specialized tools only allow apply_patch to handle moving, then I should confirm if it can manage that. It might be safest to use bash `mv` sequentially for multiple files.
-
-_Thinking:_
-
-**Evaluating file operations**
-
-The instructions say to use Bash for terminal operations but avoid it for file operations. However, renaming might be an exception since there isn't a dedicated rename tool. Given that I've verified the necessary documentation exists, I could run `mv` commands cautiously and ensure the files are accessible. I think a safer approach would be to use apply_patch for any content changes and then update AGENTS. It might be helpful to read through more documentation for additional clarity.
-
-_Thinking:_
-
-**Updating documents and references**
-
-I need to know the titles and possibly any internal numbering. I could check the content if necessary, but I think I've got enough for now. First, I’ll search for numbered headings using a grep pattern, like `^#+ .*([0-9]+\.)` and `^\d+\.` to decide how to interpret things. After renaming in the root, I'll also search for document references. I want to keep everything sharp, so I might compress some stale ranges later. Let’s explore that numbering in the documents quickly!
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "^#{1,6} .*?[0-9]+[\\.:]",
- "path": "/home/alex/projects/payroll/docs",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-Found 11 matches
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md:
- Line 17: ## Phase 0: Foundation and partner design
- Line 49: ## Phase 1: Core ledger and instant payout access
- Line 86: ## Phase 2: Analytics and stored balance
- Line 113: ## Phase 3: Card and retention tools
- Line 137: ## Phase 4: Scale features and controlled advance pilot
-
-/home/alex/projects/payroll/docs/01-core-idea.md:
- Line 37: ### 1. Payment collection or orchestration
- Line 42: ### 2. Commission rules engine
- Line 48: ### 3. Ledger and balances
- Line 54: ### 4. Instant access rails
- Line 60: ### 5. Employer analytics
- Line 66: ### 6. Optional later financing layer
-```
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "^[0-9]+\\. ",
- "path": "/home/alex/projects/payroll/docs",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-Found 30 matches
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md:
- Line 180: 1. prove employer demand for payment-linked commission automation
- Line 181: 2. prove worker demand for instant access to eligible balances
- Line 182: 3. prove safe operating rules around reversals and disputes
- Line 183: 4. prove that analytics improves employer retention
- Line 184: 5. prove that cards increase balance retention
- Line 185: 6. only then test employer-backed advance products
-
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md:
- Line 21: 1. Turn every sale into an instantly accessible commission.
- Line 22: 2. Give sales teams instant access to earned commissions.
- Line 23: 3. Real-time commissions for modern sales teams.
- Line 24: 4. The fastest way to move from customer payment to salesperson payout.
- Line 25: 5. Commission payouts, employer controls, and worker access in one platform.
- Line 29: 1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.
- Line 30: 2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.
- Line 31: 3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.
- Line 109: 1. Talk to us about your commission workflow.
- Line 110: 2. See how real-time commission payouts could work for your team.
- Line 111: 3. Become a design partner.
- Line 112: 4. Explore a commission infrastructure demo.
-
-/home/alex/projects/payroll/docs/02-brazil-market.md:
- Line 136: 1. acesso ao que ja foi ganho e validado
- Line 137: 2. liberacao conservadora de parte do saldo antes da liquidacao total
- Line 138: 3. adiantamento com respaldo do empregador
- Line 139: 4. so depois, se fizer sentido, credito com underwriting proprio
-
-/home/alex/projects/payroll/docs/01-core-idea.md:
- Line 26: 1. A customer makes a payment.
- Line 27: 2. The platform receives the payment event directly, or receives trusted payment data from a partner.
- Line 28: 3. A commission engine applies employer-defined rules.
- Line 29: 4. The internal ledger allocates balances between employer and employee.
- Line 30: 5. A safe portion of the employee's commission becomes available immediately.
- Line 31: 6. The employee can cash out instantly, and later can also spend from a wallet or card.
- Line 32: 7. The employer gets the remaining balance on a defined settlement schedule.
- Line 33: 8. Both sides get visibility into earnings, payouts, and performance.
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 47.6s)
-
-_Thinking:_
-
-**Considering document numbering**
-
-I’m thinking it might be best to remove numeric prefixes from document filenames and maybe even from the internal numbered list in the README. There’s not enough clarity yet, so I need to inspect the documents for any unnecessary numbering. Our to-do indicates that we should rename files and update references, so we can tackle that. However, I wonder if we should also consider removing numbering from titles and headings where it serves just for sequence. Let's work out a reasonable default interpretation.
-
-_Thinking:_
-
-**Evaluating document updates**
-
-It seems wise to implement the likely intended interpretation and later note if they meant heading numbering too. I think we might manage both: removing numeric prefixes from filenames while keeping internal numbering. The phrase about dropping numbering in the docs seems to apply mainly to filenames, as they’re currently numbered for order. I can rename documents to non-numbered titles and update AGENTS and README references. I’ll also create a review file for any ideas not captured, possibly under docs/review-gaps.md or docs/unincluded-ideas.md. The session transcripts could stay with their old names.
-
-_Thinking:_
-
-**Considering session transcript updates**
-
-I’m thinking we probably shouldn't modify session transcripts, as they are historical records. However, if the user wants numbering removed, I might update references in those transcripts. It seems unnecessary to rewrite them entirely, but I should note that older filenames are still mentioned in the logs.
-
-I need to ensure that AGENTS references are updated to new file names since that’s important for repo instructions. I could also look into updating any documentation cross-references after renaming. Additionally, it might be more efficient to use Bash `mv` for renaming files.
-
-_Thinking:_
-
-**Planning file operations and documentation**
-
-The developer mentioned using Bash for terminal operations like git, builds, and tests, while specialized tools are preferred for file operations. I see that renaming isn’t directly supported, but I could use apply_patch with "Update File" to rename files. Additionally, I need to create a README and another separate file. It seems applying a multi-file patch with moves and additions might work well.
-
-I'll inspect the documentation for context, especially for README summaries. I think we can summarize key points from AGENTS and create a review file for ideas not yet included. I need to choose a name for that document too!
-
-_Thinking:_
-
-**Creating review documentation**
-
-The user asked me to add anything not included in the docs to a separate file for future review. I’m considering names like `docs/review-not-yet-included.md` or `docs/ideas-to-review.md`, but maybe something like `docs/gap-review-notes.md` is better since the repo focuses on strategy. This new file should maintain English as the default language, except for Brazil.
-
-I should clearly label the contents, mentioning "ideas from conversation that are not yet captured" and possibly note any that are excluded due to conflicts.
-
-_Thinking:_
-
-**Considering file additions**
-
-The user’s instruction to “add whatever is not included” suggests I should focus on both new ideas and any conflicts. It seems beneficial to create a file with sections like "Potential additions" and "Notes that conflict with the current thesis" to preserve context. I need to decide whether to include only new ideas or also underexplored ones, especially since previous discussions mentioned both. They’ll have the chance to review everything later, so I want to ensure I cover it all!
-
-_Thinking:_
-
-**Outlining file contents**
-
-I'm drafting a file to capture several key elements, such as employer-configurable availability rules, analytics on target progress and refund rates, and pricing concepts like volume-based discounts. There’s a thought about incentivizing companies to keep funds on-platform, although that could conflict with retention strategies. I also want to include revenue designs for employer-backed advances, explicit user messaging about withdrawals, and details on refund policies. It seems some of this is documented, but I need to clarify what's missing regarding employer-set policies.
-
-_Thinking:_
-
-**Clarifying analytics and pricing**
-
-I’m considering including employee-level performance drop alerts in the analytics section, along with volume-based discounts and pricing tiers. For advances, I want to note employer fee-sharing. There's a thought about offering advanced analytics as an add-on service, but I may not have explicitly listed that before. So, in my summary of new items, I need to ensure I mention employer-configurable rules, specific analytics modules, fee-sharing, and clear user messages. Advanced analytics might fit into broader pricing strategies.
-
-_Thinking:_
-
-**Considering documentation changes**
-
-I'm thinking about searching for old filenames after renaming to ensure there are no live document references left, except for sessions, which might be useful for historical transcripts. The user mentioned dropping numbering in the docs, so I should check if there are numbered headings in the documents. There are headings like "### 1. Payment collection" and "## Phase 0" that might need removal as well. I'll need to weigh the importance of keeping internal numbering if it's meaningful versus the user's request.
-
-_Thinking:_
-
-**Evaluating documentation numbering**
-
-I think it makes sense to remove arbitrary numbering from the documents where it's not necessary. For instance, in `core-idea.md`, removing numbers from subsection headings like "### 1. Payment collection" seems fine because the order will remain clear. In `roadmap-12-months.md`, while the phases are chronological, I could consider renaming "Phase 0/1/2/3/4" to descriptive titles such as "Foundation and partner design." Preserving month ranges while dropping numbering could simplify things. Additionally, the sequential list could be transformed into bullet points for clarity.
-
-_Thinking:_
-
-**Evaluating document formatting**
-
-I'm considering the user's request to convert numbered lists into bullet points in various documents, like `brazil-market.md` and `core-idea.md`. Numbering is meaningful in step-by-step processes, but I could simplify documents where sequencing is clear. It feels like a good approach to enhance readability. I’m thinking of removing numeric prefixes from filenames and headings as well, as this could lead to cleaner documentation overall, which seems to align with the user's goal.
-
-_Thinking:_
-
-**Assessing document numbering**
-
-I need to be careful about where I change numbering, especially with things like "12-Month Roadmap" or "Months 0-2," since they're part of the content. The user's request to drop numbering seems focused on numeric prefixes rather than meaningful content. Keeping the filename as `roadmap-12-months.md` could still make sense, as "12-month" is key for context. However, I can remove decorative numbering in headings like `### 1. Payment collection or orchestration`, while keeping the important numerical references intact.
-
-_Thinking:_
-
-**Reconsidering list formats**
-
-I'm thinking about the user's request to convert numbered options into bullets. For the Brazil document, the sequence list under financial progression could switch to bullets easily. But in the core idea section where the numbered 1-8 workflow is used, I wonder if I should keep it since it's part of a process flow. However, the "drop numbering" request might mean it should be bullet points instead. There’s definitely a balance to strike here!
-
-_Thinking:_
-
-**Evaluating list clarity**
-
-I'm considering the use of bullets, keeping the top-down order but wondering if it reduces clarity. Maybe I should convey the sequence by wording it like "The product flow is:" or "The product works in this order:" which implies order without visible numbering. I think I'll inspect the core ideas in that section and the revenue model lists. Checking all documents for numbered lists could help with any conversions needed.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/01-core-idea.md",
- "offset": 20,
- "limit": 70
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/01-core-idea.md
-file
-20: - There is rarely a clear view of what has been earned, what is available, and what is still pending.
-21:
-22: ## The product
-23:
-24: The product sits between customer payment collection and employer payout.
-25:
-26: 1. A customer makes a payment.
-27: 2. The platform receives the payment event directly, or receives trusted payment data from a partner.
-28: 3. A commission engine applies employer-defined rules.
-29: 4. The internal ledger allocates balances between employer and employee.
-30: 5. A safe portion of the employee's commission becomes available immediately.
-31: 6. The employee can cash out instantly, and later can also spend from a wallet or card.
-32: 7. The employer gets the remaining balance on a defined settlement schedule.
-33: 8. Both sides get visibility into earnings, payouts, and performance.
-34:
-35: ## Core product layers
-36:
-37: ### 1. Payment collection or orchestration
-38:
-39: - Accept customer payments directly, or integrate with the employer's processor.
-40: - Use payment events as the source of truth for commission creation.
-41:
-42: ### 2. Commission rules engine
-43:
-44: - Support percentage-based, tiered, and custom rules.
-45: - Lock an auditable calculation for every sale or payment event.
-46: - Track exceptions, reversals, and dispute states.
-47:
-48: ### 3. Ledger and balances
-49:
-50: - Maintain an internal double-entry ledger.
-51: - Track at least three states: `earned`, `available`, `settled`.
-52: - Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.
-53:
-54: ### 4. Instant access rails
-55:
-56: - Phase 1: instant bank transfer or `Pix` cash-out.
-57: - Phase 2: stored balance inside the app.
-58: - Phase 3: prepaid or debit card linked to the balance.
-59:
-60: ### 5. Employer analytics
-61:
-62: - Real-time commission liability.
-63: - Sales staff performance based on actual money movement.
-64: - Forecasts for payouts, reserve needs, and commission trends.
-65:
-66: ### 6. Optional later financing layer
-67:
-68: - Employer-backed advances.
-69: - True risk-based credit only after the business has reliable repayment and reversal data.
-70:
-71: ## Recommended money flow
-72:
-73: The safest early structure is partner-led custody.
-74:
-75: - A regulated bank or licensed financial partner holds funds.
-76: - The platform owns the application layer, commission logic, ledger, and payout orchestration.
-77: - Cards, `Pix`, KYC, and regulated money movement are handled through partners.
-78:
-79: Example flow:
-80:
-81: ```text
-82: Customer pays R$1,000
-83: |
-84: v
-85: Partner-held account receives funds
-86: |
-87: v
-88: Commission engine calculates split
-89: |
-
-(Showing lines 20-89 of 197. Use offset=90 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/02-brazil-market.md",
- "offset": 120,
- "limit": 30
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/02-brazil-market.md
-file
-120: - Direito do trabalho: natureza da comissao, reflexos em folha, desconto de adiantamentos, regras contratuais com empregador.
-121: - LGPD: dados financeiros e de performance do colaborador.
-122: - CDC e transparencia: fees, prazos, disponibilidade e regras de estorno.
-123:
-124: Recomendacao pratica:
-125:
-126: - comecar debaixo da licenca e da infraestrutura de um parceiro regulado
-127: - evitar custodia direta no inicio
-128: - evitar vender o produto inicial como emprestimo
-129:
-130: ## Como tratar `vales`
-131:
-132: No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.
-133:
-134: Sequencia recomendada:
-135:
-136: 1. acesso ao que ja foi ganho e validado
-137: 2. liberacao conservadora de parte do saldo antes da liquidacao total
-138: 3. adiantamento com respaldo do empregador
-139: 4. so depois, se fizer sentido, credito com underwriting proprio
-140:
-141: Mensagem correta:
-142:
-143: - nao: `emprestimo para vendedor`
-144: - sim: `acesso controlado a comissao ja gerada`
-145:
-146: ## Go-to-market no Brasil
-147:
-148: ### Primeiro movimento
-149:
-
-(Showing lines 120-149 of 191. Use offset=150 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md",
- "offset": 15,
- "limit": 120
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md
-file
-15: ## Short positioning line
-16:
-17: Turn every sale into an instantly usable commission balance.
-18:
-19: ## Headline options
-20:
-21: 1. Turn every sale into an instantly accessible commission.
-22: 2. Give sales teams instant access to earned commissions.
-23: 3. Real-time commissions for modern sales teams.
-24: 4. The fastest way to move from customer payment to salesperson payout.
-25: 5. Commission payouts, employer controls, and worker access in one platform.
-26:
-27: ## Subhead options
-28:
-29: 1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.
-30: 2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.
-31: 3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.
-32:
-33: ## Product pillar copy
-34:
-35: ### Real-time commission engine
-36:
-37: Calculate commissions from verified payment events instead of waiting for payroll cycles and spreadsheet reconciliations.
-38:
-39: ### Instant worker access
-40:
-41: Give employees access to eligible commission balances right away, starting with instant cash-out and later expanding to wallet and card spend.
-42:
-43: ### Employer control and auditability
-44:
-45: Set payout rules, track reserve logic, and keep a reliable audit trail across every sale, split, payout, and adjustment.
-46:
-47: ### Payment-linked performance data
-48:
-49: See team performance, commission liability, and payout trends from real money movement rather than disconnected reporting tools.
-50:
-51: ## Employer value props
-52:
-53: - Reduce manual commission operations.
-54: - Replace informal advances with a controlled workflow.
-55: - Improve salesperson retention and motivation.
-56: - Get a clearer view of commission cost and team performance.
-57: - Create a better employee experience without building internal fintech operations.
-58:
-59: ## Employee value props
-60:
-61: - See what you have earned sooner.
-62: - Access eligible commissions faster.
-63: - Stop relying on informal paycheck advances.
-64: - Track progress and earnings in one place.
-65: - Later, spend directly from your balance.
-66:
-67: ## Messaging to avoid
-68:
-69: - Avoid describing the product as a payday loan.
-70: - Avoid leading with float economics or holding customer cash.
-71: - Avoid broad claims about replacing payroll or becoming a bank.
-72:
-73: ## Best narrative arc for a homepage
-74:
-75: ### Hero
-76:
-77: Headline plus a subhead focused on real-time commission access.
-78:
-79: ### Problem section
-80:
-81: Show the old flow: sale now, commission later, advance requests in between.
-82:
-83: ### Solution section
-84:
-85: Show the new flow: payment event, commission split, available balance, instant access.
-86:
-87: ### Employer section
-88:
-89: Focus on automation, controls, and analytics.
-90:
-91: ### Employee section
-92:
-93: Focus on liquidity, visibility, and trust.
-94:
-95: ### Proof section
-96:
-97: Use three proof points:
-98:
-99: - built around verified payment events
-100: - instant payout access
-101: - auditable employer controls
-102:
-103: ### CTA section
-104:
-105: Push a design-partner conversation, not a self-serve signup.
-106:
-107: ## CTA options
-108:
-109: 1. Talk to us about your commission workflow.
-110: 2. See how real-time commission payouts could work for your team.
-111: 3. Become a design partner.
-112: 4. Explore a commission infrastructure demo.
-113:
-114: ## Sample hero copy
-115:
-116: ### Option A
-117:
-118: Headline: Turn every sale into an instantly accessible commission.
-119:
-120: Subhead: We help commission-heavy businesses calculate payouts from real payment events, give teams faster access to eligible earnings, and keep employer controls and visibility in one place.
-121:
-122: CTA: Become a design partner
-123:
-124: ### Option B
-125:
-126: Headline: Real-time commissions for modern sales teams.
-127:
-128: Subhead: Replace delayed commission cycles and informal advances with a payment-linked ledger, instant payout access, and cleaner employer operations.
-129:
-130: CTA: See the workflow
-131:
-132: ## Elevator pitch
-133:
-134: We are building the financial operating layer between customer payments and salesperson earnings. Employers get automated commission calculation and better visibility. Sales teams get faster access to earned commissions. The result is a more trusted, more useful, and more immediate commission system.
-
-(End of file - total 134 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/05-roadmap-12-months.md",
- "offset": 160,
- "limit": 30
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md
-file
-160:
-161: ## What should stay out of scope in year one
-162:
-163: - standalone consumer lending
-164: - full payroll replacement
-165: - broad international expansion
-166: - feature-heavy consumer banking experience
-167: - deep CRM functionality
-168:
-169: ## Year-one product philosophy
-170:
-171: The roadmap should stay disciplined.
-172:
-173: - build the commission ledger first
-174: - prove instant access to earned money second
-175: - add retention tools third
-176: - add credit only after the company has the data and controls to support it
-177:
-178: ## Recommended milestone sequence
-179:
-180: 1. prove employer demand for payment-linked commission automation
-181: 2. prove worker demand for instant access to eligible balances
-182: 3. prove safe operating rules around reversals and disputes
-183: 4. prove that analytics improves employer retention
-184: 5. prove that cards increase balance retention
-185: 6. only then test employer-backed advance products
-
-(End of file - total 185 lines)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 88.5s)
-
-_Thinking:_
-
-**Addressing user request**
-
-The user asked to "drop the numbering in the docs," which means I need to make some changes. This includes adding a separate file for missing ideas and creating a README index. I'm inspecting the repository, considering whether to rename the docs and remove numeric prefixes from filenames. I’ll also check AGENTS for any references to the numbered file names. It seems the user wants to clarify his request regarding both filenames and content numbering, which feels a bit ambiguous.
-
-_Thinking:_
-
-**Interpreting user instructions**
-
-The user requested to "add a README index for the documents" and "drop the numbering in the docs." This could refer to filenames like `01-core-idea.md`. We need to rename the document files to remove numeric prefixes, and there might also be numbered headings or ordered lists to consider. However, it seems most likely that the focus is on filename structure. To be safe, I'll rename the files but keep meaningful internal list numbering since the user didn't specifically mention those. I'll clarify that we interpreted their request as removing numeric filename prefixes.
-
-_Thinking:_
-
-**Deciding on document structure**
-
-The developer mentioned that the default setup works without additional requests. I'm considering whether to rename file headings, like "Phase 0" and "1." lists, but that feels a bit too broad. Perhaps I should only remove numbering from the filenames while keeping the content numbering intact. For the README index, maybe a bullet list would be better than a numbered one. I need to inspect the file contents thoroughly to create a proper review file and README, and possibly read more of the documentation for accurate descriptions. I'll also need to decide on some names.
-
-_Thinking:_
-
-**Organizing ideas for review**
-
-The user wants me to add any uncovered ideas into a separate file, without modifying the existing documentation. I’ll likely create a new document, maybe titled `docs/ideas-to-review.md` or `docs/review-notes-unscoped-ideas.md`. I’ll focus on including genuinely new items and avoid anything that conflicts. Some ideas to consider are employer-configurable availability controls and explicit analytics modules, as well as clearer user-facing messaging on financial terms. Including a "do not adopt as-is" section might be helpful too.
-
-_Thinking:_
-
-**Considering documentation structure**
-
-The user requested that I include everything not in the docs, which means I'd need to address conflicting ideas like direct custody and early float. Since they're contrary to the current plan, maybe a separate file should capture both potential additions and ideas that don't align with the thesis. I could create a section explaining conflicts to document reasons why they're not included. Also, I should ensure the new file maintains English as the default and update the README index with relevant info about the repository.
-
-_Thinking:_
-
-**Deciding on session transcripts**
-
-I noticed there are many session transcripts, but since they represent past contexts, I think they should remain unchanged. The references found in `sessions/*.md` indicate these are historical records. Renaming documents could make some references in the transcripts outdated, which might confuse future readers. However, the user only asked to drop numbering in the active repo docs, not in the sessions. So, I’ll probably leave the transcripts as they are and focus on updating the current documentation like AGENTS and the new README.
-
-_Thinking:_
-
-**Evaluating file organization**
-
-I need to think about appropriate file names for renaming. Options include `core-idea.md`, `brazil-market.md`, `market-memo.md`, `positioning-and-landing-copy.md`, and `roadmap-12-months.md`. Maybe I should drop numbering in the documentation, but I won’t rename the root `docs` directory.
-
-I also need to create a separate review file. I could call it `docs/ideas-to-review.md` since the user mentioned needing it for later review. That sounds descriptive and stable!
-
-_Thinking:_
-
-**Considering thesis additions**
-
-I’m thinking about potential additions to my thesis. I’ll consider employer-set availability controls based on policies, explicit analytics modules for tracking performance, and advance economics like fee sharing. I want to explore tiered employer pricing and clear messaging for employees about their earnings and withdrawal timelines.
-
-Some ideas came up, but they seem misaligned with my current plan, like direct custody and early lending, so I'll note those for later just in case.
-
-_Thinking:_
-
-**Updating documentation**
-
-I’m thinking about how to structure the documentation so the user can review it later. It might be useful to include status tags like "candidate addition" or "not aligned." I should consider updating the README and AGENTS files to reference a new review file, "docs/ideas-to-review.md," and maybe include a list of canonical documents.
-
-The focus should remain on important documentation, with references to AGENTS.md and sessions if needed. However, I need to ensure any internal instructions are updated to reflect the new file paths to avoid confusion.
-
-_Thinking:_
-
-**Updating README index**
-
-I think I need to update the document index order in the README. It might be useful to create a section titled "Suggested Reading Order" or maybe just a bullet list for clarity. The numbering has been removed, but since the user still wants an index, this could help organize the information. Keeping things clear and concise will definitely enhance the user's experience. So, I'll make those changes to ensure it’s user-friendly!
-
-_Thinking:_
-
-**Organizing file operations**
-
-I need to check if the parent directory exists, and it does according to the docs. For renaming, the instruction says to use `ls` to verify the parent directory before creating anything new. I've already read the directory, so that’s good! I can use Bash for renaming with `mv`, but it might be better to consider specialized tools. Maybe `apply_patch` can help with renaming and updating files like AGENTS and README content? I'll need to draft this carefully, particularly with file references! Also thinking about potential repo names like "Commission Infrastructure Thesis."
-
-_Thinking:_
-
-**Exploring commission control features**
-
-I’m thinking about a holding area for later review, rather than a fixed plan.
-
-For employer availability controls, it could be helpful to let employers dictate how commission becomes available, showing clear limits and policies to employees.
-
-I also see potential in adding more analytical modules to track employee and team progress while providing insights into refund rates and alerts for performance drops.
-
-Lastly, exploring employer-backed advance pricing could be a beneficial later feature.
-
-_Thinking:_
-
-**Considering file operations**
-
-I'm unsure if `apply_patch` requires content context after the Update File and Move commands. Maybe including an empty hunk would work? The example suggests using a hunk with content changes, but I could also use Bash `mv` commands, which seems simpler. Yet the developer recommends `apply_patch` for single file edits. Since renaming is a file operation, but `apply_patch` can manage renames, I need to check if it supports renaming without any content change. This could work.
-
-_Thinking:_
-
-**Planning file updates**
-
-I need to include these specific updates: first updating the file at `/home/alex/projects/payroll/docs/01-core-idea.md`, then moving it to `/home/alex/projects/payroll/docs/core-idea.md`. It seems this might work, but I need to test it. I could combine all moves into one patch and create another for the AGENTS and README files, or keep them in the same patch. Doing two patches might be more manageable: one for moves and one for new or updated files.
-
-_Thinking:_
-
-**Considering document formatting**
-
-I’m thinking we might want to remove numbering from section headings and ordered lists since the user suggested dropping numbering in the docs. This could align with a cleaner style. However, they didn't mention filenames, so maybe we should still keep numbered filenames. It’s a tricky balance. I’m considering renaming doc files and heading subsections to remove numeric prefixes, but I wonder how this might alter the meaning or order. It’s something to think about!
-
-_Thinking:_
-
-**Clarifying user instructions**
-
-The user asked to drop the numbering in the documents, but it's a bit ambiguous. It might mean removing numeric prefixes from filenames while keeping the meaningful ordered lists intact. I'll interpret it as removing those prefixes, but I wonder if I should also eliminate obvious numeric labels in headings and numbered option lists. It seems like that might create a more consistent style with non-numbered filenames, which could be a good result! Let's weigh the pros of this change.
-
-_Thinking:_
-
-**Evaluating document organization**
-
-There are some cons to consider here. While it might take more time to change, it's manageable. Some lists should probably stay numbered since their order matters or they’re referenced by number. I could change examples like "Headline options" and "CTA options" into bullet points.
-
-For sequences such as the "Recommended milestone sequence," I wonder if I should keep numbering for clarity. However, since the user asked to drop numbering, I can use bullet points and descriptive headings to convey order instead.
-
-_Thinking:_
-
-**Reassessing lists and styles**
-
-The section under "The product" is more of a process flow, so I think I can convert it to bullets instead of keeping numbers. For the "Recommended sequence," I could format it with phrases like "Start by..." and "Then..." That applies to the "Sequencia recomendada" in `brazil-market.md`, where I could use terms like "primeiro" and "depois."
-
-Since the user asked to drop the numbering in the docs, it’s clear they might prefer a cleaner style without numbered lists. They also requested an index for the README, which is a good idea!
-
-_Thinking:_
-
-**Updating roadmap headings**
-
-I need to read the roadmap sections to update the headings. I think I need the full file if I'm modifying them. I might consider using a simple search and replace, possibly through apply_patch. So, I’ll inspect the relevant sections around phase headings and lists. I’ve already found information in sections 04 and 02, but I want to see more of the roadmap to get a complete view.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/05-roadmap-12-months.md",
- "offset": 1,
- "limit": 170
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/05-roadmap-12-months.md
-file
-1: # 12-Month Roadmap
-2:
-3: ## Guiding principle
-4:
-5: Do not start by building a broad neobank or a consumer lending app.
-6:
-7: Start with the smallest product that proves the core wedge:
-8:
-9: `payment-linked commission calculation plus instant access to earned balances`
-10:
-11: ## Success goal for year one
-12:
-13: By the end of 12 months, the company should prove that employers will adopt a commission-led payout workflow and that employees will use it for faster access to earnings.
-14:
-15: The year-one target is not maximum feature breadth. It is proof of product-market fit for the core loop.
-16:
-17: ## Phase 0: Foundation and partner design
-18:
-19: ### Months 0-2
-20:
-21: #### Objectives
-22:
-23: - validate the first customer segment
-24: - choose partner model for custody, payouts, and compliance
-25: - lock the ledger and commission system design
-26:
-27: #### Workstreams
-28:
-29: - run design-partner interviews with target employers
-30: - map employer commission workflows and exception cases
-31: - choose payment and banking partner shortlist
-32: - define balance states: `earned`, `available`, `settled`
-33: - define reserve and holdback logic for reversals
-34: - specify onboarding flows for employers and employees
-35:
-36: #### Deliverables
-37:
-38: - product requirements for v1
-39: - legal and regulatory issue map
-40: - partner shortlist and integration plan
-41: - event model for payments, commissions, adjustments, and payouts
-42:
-43: #### Exit criteria
-44:
-45: - 5 to 10 serious design partners in pipeline
-46: - clear v1 scope that does not depend on lending
-47: - chosen path for `Pix` and custody infrastructure
-48:
-49: ## Phase 1: Core ledger and instant payout access
-50:
-51: ### Months 2-5
-52:
-53: #### Objectives
-54:
-55: - launch the first working employer flow
-56: - prove that a verified sale can become an eligible commission balance
-57: - enable instant cash-out for employees
-58:
-59: #### Product scope
-60:
-61: - employer onboarding
-62: - employee onboarding through partner KYC
-63: - payment ingestion or payment reconciliation
-64: - commission rules engine
-65: - internal ledger
-66: - employee balance with `earned`, `available`, and `settled`
-67: - employer settlement scheduling
-68: - instant payout access via `Pix` or equivalent instant transfer rail
-69: - employer dashboard with payout and commission views
-70: - employee dashboard with balance and payout history
-71:
-72: #### Operational scope
-73:
-74: - manual support for edge cases
-75: - conservative limits on instant availability
-76: - dispute and adjustment workflows
-77:
-78: #### Metrics
-79:
-80: - number of active employers
-81: - commission volume processed
-82: - payout latency
-83: - adjustment and reversal rate
-84: - employee activation rate
-85:
-86: ## Phase 2: Analytics and stored balance
-87:
-88: ### Months 5-8
-89:
-90: #### Objectives
-91:
-92: - make the product more valuable to employers
-93: - improve employee retention of balances
-94: - reduce the need for manual reporting
-95:
-96: #### Product scope
-97:
-98: - stored balance in the app
-99: - clearer balance segmentation and reserve visibility
-100: - employer analytics for team performance and commission liability
-101: - projections for upcoming payouts
-102: - employee insights on earnings pace and history
-103: - alerts for anomalies and budget spikes
-104: - admin tools for corrections and policy configuration
-105:
-106: #### Metrics
-107:
-108: - percent of balances retained in-platform
-109: - dashboard usage by employers
-110: - frequency of manual interventions
-111: - repeat payout behavior per employee
-112:
-113: ## Phase 3: Card and retention tools
-114:
-115: ### Months 8-10
-116:
-117: #### Objectives
-118:
-119: - make the balance more useful without requiring immediate cash-out
-120: - unlock interchange economics
-121:
-122: #### Product scope
-123:
-124: - prepaid or debit card issuance through a partner
-125: - spend from available balance
-126: - card controls and transaction views
-127: - balance retention incentives tied to usage, not explicit interest promises
-128: - stronger notifications and mobile experience
-129:
-130: #### Metrics
-131:
-132: - card activation rate
-133: - card spend volume
-134: - balance retention before and after card launch
-135: - support load per active user
-136:
-137: ## Phase 4: Scale features and controlled advance pilot
-138:
-139: ### Months 10-12
-140:
-141: #### Objectives
-142:
-143: - deepen product value for employers
-144: - test a tightly controlled version of advance functionality without becoming credit-led
-145:
-146: #### Product scope
-147:
-148: - multi-entity or franchise support
-149: - API or integration layer for ERP, CRM, or POS tools
-150: - employer cash flow forecasting
-151: - pilot of employer-backed advances with strict limits
-152: - improved risk rules for refunds, clawbacks, and employee exits
-153:
-154: #### Metrics
-155:
-156: - employer expansion within existing accounts
-157: - integration adoption
-158: - advance usage and repayment behavior
-159: - loss or exception rate on pilot advances
-160:
-161: ## What should stay out of scope in year one
-162:
-163: - standalone consumer lending
-164: - full payroll replacement
-165: - broad international expansion
-166: - feature-heavy consumer banking experience
-167: - deep CRM functionality
-168:
-169: ## Year-one product philosophy
-170:
-
-(Showing lines 1-170 of 185. Use offset=171 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/02-brazil-market.md",
- "offset": 130,
- "limit": 20
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/02-brazil-market.md
-file
-130: ## Como tratar `vales`
-131:
-132: No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.
-133:
-134: Sequencia recomendada:
-135:
-136: 1. acesso ao que ja foi ganho e validado
-137: 2. liberacao conservadora de parte do saldo antes da liquidacao total
-138: 3. adiantamento com respaldo do empregador
-139: 4. so depois, se fizer sentido, credito com underwriting proprio
-140:
-141: Mensagem correta:
-142:
-143: - nao: `emprestimo para vendedor`
-144: - sim: `acesso controlado a comissao ja gerada`
-145:
-146: ## Go-to-market no Brasil
-147:
-148: ### Primeiro movimento
-149:
-
-(Showing lines 130-149 of 191. Use offset=150 to continue.)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md",
- "offset": 19,
- "limit": 100
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md
-file
-19: ## Headline options
-20:
-21: 1. Turn every sale into an instantly accessible commission.
-22: 2. Give sales teams instant access to earned commissions.
-23: 3. Real-time commissions for modern sales teams.
-24: 4. The fastest way to move from customer payment to salesperson payout.
-25: 5. Commission payouts, employer controls, and worker access in one platform.
-26:
-27: ## Subhead options
-28:
-29: 1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.
-30: 2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.
-31: 3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.
-32:
-33: ## Product pillar copy
-34:
-35: ### Real-time commission engine
-36:
-37: Calculate commissions from verified payment events instead of waiting for payroll cycles and spreadsheet reconciliations.
-38:
-39: ### Instant worker access
-40:
-41: Give employees access to eligible commission balances right away, starting with instant cash-out and later expanding to wallet and card spend.
-42:
-43: ### Employer control and auditability
-44:
-45: Set payout rules, track reserve logic, and keep a reliable audit trail across every sale, split, payout, and adjustment.
-46:
-47: ### Payment-linked performance data
-48:
-49: See team performance, commission liability, and payout trends from real money movement rather than disconnected reporting tools.
-50:
-51: ## Employer value props
-52:
-53: - Reduce manual commission operations.
-54: - Replace informal advances with a controlled workflow.
-55: - Improve salesperson retention and motivation.
-56: - Get a clearer view of commission cost and team performance.
-57: - Create a better employee experience without building internal fintech operations.
-58:
-59: ## Employee value props
-60:
-61: - See what you have earned sooner.
-62: - Access eligible commissions faster.
-63: - Stop relying on informal paycheck advances.
-64: - Track progress and earnings in one place.
-65: - Later, spend directly from your balance.
-66:
-67: ## Messaging to avoid
-68:
-69: - Avoid describing the product as a payday loan.
-70: - Avoid leading with float economics or holding customer cash.
-71: - Avoid broad claims about replacing payroll or becoming a bank.
-72:
-73: ## Best narrative arc for a homepage
-74:
-75: ### Hero
-76:
-77: Headline plus a subhead focused on real-time commission access.
-78:
-79: ### Problem section
-80:
-81: Show the old flow: sale now, commission later, advance requests in between.
-82:
-83: ### Solution section
-84:
-85: Show the new flow: payment event, commission split, available balance, instant access.
-86:
-87: ### Employer section
-88:
-89: Focus on automation, controls, and analytics.
-90:
-91: ### Employee section
-92:
-93: Focus on liquidity, visibility, and trust.
-94:
-95: ### Proof section
-96:
-97: Use three proof points:
-98:
-99: - built around verified payment events
-100: - instant payout access
-101: - auditable employer controls
-102:
-103: ### CTA section
-104:
-105: Push a design-partner conversation, not a self-serve signup.
-106:
-107: ## CTA options
-108:
-109: 1. Talk to us about your commission workflow.
-110: 2. See how real-time commission payouts could work for your team.
-111: 3. Become a design partner.
-112: 4. Explore a commission infrastructure demo.
-113:
-114: ## Sample hero copy
-115:
-116: ### Option A
-117:
-118: Headline: Turn every sale into an instantly accessible commission.
-
-(Showing lines 19-118 of 134. Use offset=119 to continue.)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 74.2s)
-
-_Thinking:_
-
-**Updating documentation**
-
-I need to respond to the user's request by editing files. It seems the preference is to use apply_patch for single file edits. I should create a README and a separate file for gaps, while also renaming the docs to remove numbering. Updating references in the AGENTS or possibly session files is another consideration. I wonder if I need to update session transcript references since they seem historical. The user’s wording about dropping numbering is a bit ambiguous—could refer to files or the lists/headers inside.
-
-_Thinking:_
-
-**Adding README and addressing numbering**
-
-I need to add a README to the repo, which will serve as an index for the documents. The user mentioned dropping the numbering in the docs; this could mean the numbered filenames, like 01-core-idea, or it could refer to numbered headings within those docs. I should inspect the repo to see the conventions. Since the user specified "docs" without being more precise, I might consider addressing both filenames and any numbered titles inside the documents. I want to be comprehensive but cautious about making unnecessary changes.
-
-_Thinking:_
-
-**Deciding on file naming and numbering**
-
-I’m considering renaming files to remove numeric prefixes and also eliminating internal numbering in headings and lists. The phrase “in the docs” might refer to the filenames and any numbering in the content too. The instructions suggest doing non-blocked work first, but I need to determine if anything is genuinely blocked. I think it's reasonable to assume this refers to both filenames and section labels. However, changing internal lists to bullet points might alter the structure. The user wants a separate file for unincluded ideas without modifying the existing document content.
-
-_Thinking:_
-
-**Renaming documentation files**
-
-I need to address the feedback about dropping numbering in the docs. This could mean removing numbering prefixes from the document filenames and updating references accordingly. Since the user wants a README to index the documents, maybe numbering is no longer needed. I’ll consider renaming files like "docs/core-idea.md" and create a new file for open questions or gaps, possibly naming it "docs/review-notes.md" or "docs/open-ideas-to-review.md" for clarity.
-
-_Thinking:_
-
-**Structuring review notes**
-
-I need to consider how to best organize the new documentation index. The file could be named "docs/gap-review-notes.md," "docs/open-ideas-to-review.md," or "docs/ideas-for-later-review.md." This file should capture suggestions from our conversations that aren't currently in the docs. I should structure it with sections for potential additions and note that they shouldn't be incorporated as-is. The sections might include explicit product controls, analytics modules, pricing ideas, UX suggestions, and any ideas marked as conflicting with our main thesis.
-
-_Thinking:_
-
-**Creating README index**
-
-I should consider adding a note in the documentation about ideas that were "left out on purpose." This will provide clarity on what has been intentionally excluded. Also, I need to create a README index to help navigate through all the documentation effectively. I'll ensure it's clear and organized, making it easier for users to find what they're looking for and understand the reasoning behind the choices made in the documentation.
-
-_Thinking:_
-
-**Considering document formatting**
-
-I’m looking into the user’s request to drop numbering in the docs. I’m thinking about renaming files to eliminate numeric prefixes, but there are internal headings like "### 1. Payment collection..." that might be affected. It's possible these are what the user wants to change. There are also numbered phases in the roadmap and option lists in the positioning doc. I wonder if proactively removing visible numbering from headings while keeping lists intact is the best approach.
-
-_Thinking:_
-
-**Considering document numbering**
-
-I’m thinking about the user’s request regarding document numbering. They haven’t explicitly said to drop the numbering from filenames, but that seems implied since README is meant to serve as the index. I doubt they want to change numbered bullets that carry meaning, especially in the roadmap phases, which are crucial. Still, I should probably keep the important numbering for phases, like "Phase 0.” I could rename files to non-numbered names while removing numeric prefixes from section headings that are just cosmetic.
-
-_Thinking:_
-
-**Evaluating numbering for documentation**
-
-I’m considering the user’s request about numbering in the roadmap. For the phases, order is crucial, while for core product headings, numbering helps but isn’t strictly necessary. I could remove numbering from headings and maintain the sequence. For positioning and CTA options, I could switch numbered lists to bullets, which may lessen the clarity of order. However, if the user wants to drop all numbering, that could apply to every numbered list. I found around 30 numbered lists, which isn’t too many. Maybe transforming them all into bullets would satisfy their request, but I wonder if that’s being too aggressive.
-
-_Thinking:_
-
-**Changing document styles**
-
-I’m reflecting on how to adjust the document styles since they’re strategy documents. Switching from numbered phase headings like "Phase 0" to just titles like "Foundation and partner design" with month labels might work, but I would lose the numbering. I could just rely on the order of sections for chronology. Similarly, I can simplify headings like "### 1. Payment collection or orchestration" to "### Payment collection or orchestration." I think converting enumerated product flows and positioning document options to bullets is a good idea too!
-
-_Thinking:_
-
-**Considering file organization**
-
-I'm thinking about the user’s request to add a separate file, a README, and drop numbering in the documents. It makes sense to use bullet points, possibly prefixed with "first" and "then", to clarify sequence. Although they may also mean to rename files with numbering since the documents are currently sorted by those numbers. I’ll also create a todo list for these updates and might need to read more files to see where else numbering could be removed.
-
-_Thinking:_
-
-**Planning file updates**
-
-I'm considering the numbered areas I've seen from grep and my reads. While I may not need to read all files, I definitely need context when applying patches to convert numbered lists. I can make targeted patches using the right lines since I already have that context. Plus, I should remember the AGENTS.md instructions to default to ASCII when editing files. There’s also the thought about compressing stale messages, like m0006-m0018, after modifications to keep things manageable. Time to figure out my tasks more clearly!
-
-_Thinking:_
-
-**Deciding on document updates**
-
-I'm thinking about applying a patch to rename the documentation files while dropping the prefixes and possibly adjusting the internal content numbering. I need to finalize the decisions around this. I have tasks lined up: adding a `README.md`, creating a separate file for omitted ideas, and updating references in AGENTS. I should verify everything through glob, read, or grep. For file names, I could go for plain names that preserve meaning. A new review file could be either `docs/review-notes.md` or `docs/open-ideas-for-review.md`. Maybe it’s best to organize them alphabetically since numbering won't apply.
-
-_Thinking:_
-
-**Organizing documentation structure**
-
-It looks like I need to mention that `sessions/` could have transcripts and maybe a "Suggested reading path" for the user. Since they want an index for documents, the README could include a few key sections: what the repo is about, core docs, review notes, and supporting context.
-
-I think I need to create a review file that might include sections on "Potential additions not yet captured" and "Ideas intentionally excluded for now," especially since the user wants to add anything that's not currently included.
-
-_Thinking:_
-
-**Reorganizing documents**
-
-I'm thinking about converting a milestone sequence from a numbered list to bullet points, using words like "First," "Then," "Next," and so on to keep the order clear. That seems like a solid approach. I also need to look into the `docs/01-core-idea.md` file to change its numbered product list to bullets and rename the headings. For the `docs/03-market-memo.md`, I want to keep it unnumbered, except where items aren't found. That should work!
-
-_Thinking:_
-
-**Considering document formatting**
-
-I’m evaluating whether removing numbering from content would align with the user's preferences. It feels like a bit more work, but I think it’s manageable. I might keep the title “12-Month Roadmap” as is, even with the numbering in the title. I’ll also consider updating the README index to avoid numbering and suggest a reading order with verbs instead. Since we want to drop numbering, I’ll focus on using bullets in both the README and AGENTS as well.
-
-_Thinking:_
-
-**Planning file updates**
-
-I need to consider using apply_patch to rename and modify files, which could be a large patch. Since there are multiple files, I’m leaning toward doing it all in one patch to keep things organized. Careful formatting is essential, so I might update the todo list before starting the edits. I should also check the search scope to see what’s completed and what needs renaming before I proceed.
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "pending",
- "priority": "medium"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "pending",
- "priority": "medium"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 142.1s)
-
-_Thinking:_
-
-**Considering repository modifications**
-
-I need to respond to the user's request by modifying the repository. This involves managing context and possibly compressing it later. I might need to read the full documentation to understand it better. The user asked to create a README and a separate review file, and they want to drop numbering in the documents. I need to determine whether this includes renaming files and internal headings, so I'll decide on a reasonable default for both.
-
-_Thinking:_
-
-**Evaluating documentation changes**
-
-I see "in the docs" is plural, which makes me think about removing numeric prefixes from both document filenames and any internal structural numbering. We should probably do both unless I hit a roadblock. I also need to inspect the repo, as session references might be transcripts and not require updates. If I'm renaming docs, I should update the README and AGENTS. As for session transcripts, they're historical records, so perhaps I shouldn't change them to avoid altering their history.
-
-_Thinking:_
-
-**Deciding on transcript updates**
-
-I might mention that if the session transcripts are left unchanged, they’ll still include old names. Should I update them? They are repo files, but since they’re transcripts of past sessions, changing them could distort history. It's probably better not to alter them. If I find references through grep, I can ignore them since transcripts aren't part of the docs index. I should consider updating the AGENTS instructions, but I need to be careful not to violate any guidelines while editing those. I also need to create a new file for undocumented ideas and decide the best location and name for it.
-
-_Thinking:_
-
-**Considering document numbering**
-
-I’m thinking about whether to rename the directory. I feel like I need to focus on removing the numbering inside the document content since the user specified dropping it. I’ll consider that the file prefixes are obvious numbering. I wonder if they want to eliminate numbering in titles or lists, as I found headings like "### 1. Payment collection..." and lists starting with numbers as 1., 2., 3., etc. It's tricky, but I’ll figure it out!
-
-_Thinking:_
-
-**Deciding on numbering in docs**
-
-I need to consider the request about filenames and the README index together. Since they mentioned "also" when asking for the index, it seems they might want unnumbered filenames. Still, I wonder if internal numbering is acceptable? The phrase "drop the numbering in the docs" could imply filenames since those are currently numbered. I should also check if the user wants to keep phase numbers in the headings since they have meaning. There’s a lot to figure out here!
-
-_Thinking:_
-
-**Assessing numbering in documents**
-
-It looks like the user wants the docs to serve as an index without numbering, likely referring to filenames since documents had numeric indexing before. I checked the titles, and only the roadmap has a number that should stay. If they meant for all numbering to be removed, I would think they would mention that. However, I need to weigh whether internal numbering should stay. I might remove numbering from section headings and some lists, though it doesn't seem strictly necessary. I also need to rename files, which could involve using a Bash command.
-
-_Thinking:_
-
-**Exploring file update options**
-
-I see that the update file can utilize the apply_patch tool for moving and renaming, which supports functions like `*** Update File` and `*** Move to`. This could be a feasible way to rename multiple files and adjust content within one patch. However, using Bash `mv` is an alternative if needed since specific rename tools aren't available, though specialized tools are generally preferred. I should also check if internal references need updates, especially after altering contents. So it looks like I'll go with apply_patch for AGENTS and README updates!
-
-_Thinking:_
-
-**Renaming documents**
-
-I'm considering the filenames in the docs since we only found AGENTS and sessions with no references. It feels essential to rename the docs for clarity. I've thought about using names like `core-idea.md` or `brazil-market.md`. There's a need for a consistent naming style, possibly avoiding numbers entirely. Maybe I could go with `roadmap-first-year.md` instead. I’ll ensure that updates to AGENTS reflect these changes. The titles can still keep numerical references.
-
-_Thinking:_
-
-**Choosing document names**
-
-I'm reconsidering how to drop numbering in the filenames. Using something like `roadmap-year-one.md` feels like a strong choice. For instance, I might rename `04-positioning-and-landing-copy.md` simply to `positioning-and-landing-copy.md`, so there's just one file with a number in the name. I also like the idea of standardizing names without numbers at all. I could have files like `docs/core-idea.md`, `docs/brazil-market.md`, and `docs/market-memo.md`. Maybe creating a `docs/ideas-for-review.md` would be useful too!
-
-_Thinking:_
-
-**Considering document structure**
-
-I'm thinking about the numbering in section headings like "### 1. Payment collection or orchestration.” Some numbers seem more organizational than necessary. I’ll check the docs to confirm, and it appears we can switch to plain headings without numbers. For meaningful phases like `## Phase 0`, I might rename those to something more descriptive. Also, I could consider changing the milestone and product flow lists from numbered to bullet points since the order is still clear. The user did mention dropping numbering, so I need to keep that in mind!
-
-_Thinking:_
-
-**Evaluating document numbering**
-
-I’m considering whether to remove numbering from all markdown ordered lists and headers where it doesn’t add value. It might be more work, but since the user explicitly asked to drop numbering in the docs, I think it’s important to follow that. We found 30 occurrences of ordered lists across four files and 11 numbered headings. It’s manageable to convert those to bullet points. However, I’m pondering if changing this style is truly wise. Let’s think this through carefully!
-
-_Thinking:_
-
-**Assessing clarity in lists**
-
-I’m thinking about whether removing numbering will reduce clarity for sequences like product flows or milestone recommendations. Numbering really helps with sequence clarity, but the user's instruction to drop numbering may take precedence here. I could use bullets or add introductions, like "The flow is:" or arrows to indicate order. Rewriting milestone sequences and headings as bullet sentences starting with verbs might work. Since the user only addressed numbering, I wonder if it's okay to keep lettered options like "Option A/B." Removing numbering from CTA options seems reasonable too!
-
-_Thinking:_
-
-**Considering documentation updates**
-
-I’m thinking we should possibly update the README index order to reflect a recommended reading sequence instead of just being alphabetical. That could be a nice enhancement. I also feel we need a separate review file after renaming the documents, which could reference the new names. Since the user emphasized the README for indexing documents, I should ensure the AGENTS references are current as well. It might be helpful to mention the new review file in that context.
-
-_Thinking:_
-
-**Organizing documentation**
-
-I'm considering whether `docs/ideas-for-review.md` is essential, but it might be good to mention it in the backlog. Maybe I should create a README with an index of docs and include new review files. I could outline reading paths like `docs/core-idea.md` and others, making sure to note that `docs/brazil-market.md` is in pt-BR. I should rename relevant files as well, possibly using `apply_patch` for larger changes across multiple documents or considering a scripting approach for efficiency.
-
-_Thinking:_
-
-**Renaming and modifying files**
-
-I need to rename multiple files and modify their content. A Python script run through Bash could help with the renaming and changes, but specialized tools are generally preferred for file operations. The `apply_patch` tool can handle multiple operations, making it a possible choice. However, if there are many content changes, it might be cumbersome. Scripting with Python could be more efficient for bulk search-and-replace across the codebase. It sounds like using both Bash and Python for efficiency is acceptable within the editing guidelines.
-
-_Thinking:_
-
-**Considering multi-file edits**
-
-I'm looking into renaming multiple files while also editing their content. A Python script might be the most efficient method. However, there's no direct Write tool available, and the instructions suggest avoiding Bash for file operations in favor of specialized tools. Still, it seems they allow some flexibility for complex scripting if no better options exist. Since we do have the `apply_patch` tool available, I need to consider the best path forward.
-
-_Thinking:_
-
-**Evaluating file modifications**
-
-I’m looking into renaming documents and updating internal numbering. A Python script using `mv` and file manipulation seems feasible, but I could also consider the apply_patch method to update file content and move it simultaneously. I’m calculating the modifications: moving five files, adjusting content, updating AGENTS, adding a README, and a review file—potentially eight sections that could fit into a patch. I’ll need to inspect the relevant files to ensure accuracy in the updates.
-
-_Thinking:_
-
-**Planning file updates**
-
-I’m planning to create the review file and README from scratch. For the `core-idea`, I need to modify lines 24-68, but searching shows I only need to focus on certain lines—specifically lines 26-33 and headings 37 and 42. The `positioning` section will need adjustments in lines 19-31 and 107-112, while the `roadmap` requires edits around several headings. I’ll patch accordingly and handle the `brazil-market` sequence list as well. It's essential to choose new filenames carefully and update the AGENTS key in the documentation too.
-
-_Thinking:_
-
-**Choosing file names**
-
-The user wants to drop the numbering, so I have two options: `year-one-roadmap.md` or `roadmap-year-one.md`. I’m thinking that `year-one-roadmap.md` sounds clearer since it uses words instead of numbers. So, I’ll go with `year-one-roadmap.md`, and update the AGENTS path to `docs/year-one-roadmap.md`. This should align nicely with the user’s request while keeping everything organized. It feels like I’m on the right track!
-
-_Thinking:_
-
-**Reviewing advanced analytics package**
-
-I could highlight the potential of selling an advanced analytics package separately. I need to consider pricing experiments like volume tiers for employers and a premium analytics module, plus how employer-backed advances could work with fee splits. However, I should note that I didn’t explicitly mention "advanced analytics as a paid add-on" in earlier summaries. It seems that I need to make sure it’s clear in our documentation and included in new items. I might have missed emphasizing the upsell of advanced analytics.
-
-_Thinking:_
-
-**Evaluating documentation inclusions**
-
-I’m wondering if we should consider advanced analytics as not included in the current documentation. The docs discuss monetizing software and payment flow but don’t mention advanced analytics as an upsell explicitly. I think we could frame it as a pricing experiment by suggesting an advanced analytics package or a premium reporting tier. The user asked to add anything that’s not included, so I should include that. Additionally, I might note that using refund-rate data could help adjust availability and limits dynamically, as that's not explicitly mentioned in the docs either.
-
-_Thinking:_
-
-**Considering policies and pricing strategies**
-
-I'm contemplating some ideas that could enhance our policies. For example, I might include "risk-aware availability policies tied to refund behavior" without overstating things. Another thought is to address "employer-set withdrawal limits," separate from availability. I could mention pricing tiers or discounts for employers, but I want to be careful since we've discussed discounted rates to encourage companies to keep funds on-platform. I need to be cautious about later stages in this context and ensure alignment with partner-held custody.
-
-_Thinking:_
-
-**Organizing review ideas**
-
-I'm thinking about creating two sections: one for "Ideas to review later" and another for "Ideas mentioned but intentionally excluded." Since the user wants to include anything not currently in the documentation, I should add notes for those excluded ideas as well. This file can act as a parking lot for these ideas. Additionally, should I update the AGENTS to reflect these changes and include a line under Key documents for the review file? That might be really helpful!
-
-_Thinking:_
-
-**Evaluating AGENTS structure**
-
-I need to think about whether AGENTS should just include instructions without becoming too cluttered. One extra line might be fine, but I should confirm if the README file exists. Checking the working tree might be unnecessary right now. After making edits, I could run `git status --short` to verify any changes, which seems acceptable. Also, I might want to compress some older conversations later, but perhaps not just yet. Renaming documents and making content adjustments sounds like a good plan!
-
-_Thinking:_
-
-**Considering proof points**
-
-I think about whether I should change "Use three proof points" to something else. Removing numbering could simplify things, making it feel less rigid and more conversational. I want to ensure it flows well and doesn’t come off as too formal. Adjusting the phrasing could make communicating ideas feel more engaging! So, I’ll consider alternatives that still convey the same message but in a friendlier way. Let’s see what fits best!
-
-_Thinking:_
-
-**Refining documentation format**
-
-I'm considering removing the numbering from the title, changing it to `# Year-One Roadmap`, which seems more consistent. The user mentioned dropping numbers in the docs, so it makes sense. However, I still have numbered sections like `### Months 0-2`. Those are time ranges and might be necessary. But changing them to `### Months zero to two` feels awkward. I could also update references in `AGENTS.md` and adjust the path for a specific document.
-
-_Thinking:_
-
-**Updating document structure**
-
-I'm thinking about renaming the roadmap file to `docs/year-one-roadmap.md`, which seems good. I also need to add a README. It would be helpful to include `docs/ideas-for-review.md` in the README.
-
-For the README, I envision a structure that includes a short description, document index, suggested reading order, and notes about language preferences, while clarifying that the repository stores strategy docs, not code. I might also want to mention the ideas file explicitly.
-
-_Thinking:_
-
-**Reviewing external ideas**
-
-I see this file contains ideas discussed in external conversations that haven't been incorporated into the main documents yet. It's important to collect and integrate these insights because they might add value or provide different perspectives. I should take time to evaluate what's in this file, see which points are most relevant, and consider how they can enhance the current documentation. It's all about keeping the information comprehensive and up-to-date!
-
-_Thinking:_
-
-**Reviewing potential additions**
-
-This document serves as a collection of ideas for future review rather than a finalized plan. First, adding employer availability controls could help; allowing employers to configure how much of the earned commission is accessible right away. It’s also important to clarify balance messaging for employees, so they understand when they can withdraw funds. Deeper analytics modules could aid performance tracking and alert systems. Lastly, we should evaluate potential pricing tiers based on volume and complexity for employers. This seems like a comprehensive approach to improving the system.
-
-_Thinking:_
-
-**Defining employer-backed advances**
-
-I need to outline the economics of employer-backed advances, including whether any fees will be shared with employers. If we consider retained-balance incentives later, I want to ensure they align with partner-held custody, avoiding float as the main selling point. There are additional ideas to revisit that don't fit the current focus, like direct custody of customer funds or making advances a primary feature early on. We might also want to note using refund-rate data to adjust availability policies. Perhaps I should create a separate document for these ideas.
-
-_Thinking:_
-
-**Considering AGENTS updates**
-
-I’m thinking about whether to update the `AGENTS` document to include notes on pricing design and other areas worth exploring later. It might be helpful for future reference, even if the user requested a separate file. Adding this could provide clarity, though editing `AGENTS` may not be necessary. I also want to consider whether I need to update sessions, but I’m leaning against that. It’s possible that a simple README index and the AGENTS notes will suffice.
-
-_Thinking:_
-
-**Drafting modifications carefully**
-
-I need to include all file additions and modifications, so I'll draft meticulously for the `core-idea`. I’m looking at moving some content and reorganizing the patch from lines 22-68. It seems like I should replace the numbered list and headings with a new format. The sequence starts with customer payment collection and employer payout, and I want to ensure everything is clear and concise throughout.
-
-_Thinking:_
-
-**Revising the product description**
-
-I want to outline how both sides have visibility into earnings, payouts, and performance. The product functions between customer payment collection and employer payouts. It starts when a customer makes a payment. The platform either directly receives the payment event or trusted data from a partner. Then, a commission engine applies employer-defined rules, and the internal ledger allocates balances between employer and employee. A portion of the employee’s commission is available immediately. The employer receives the remaining balance on a defined schedule.
-
-**Tool: apply_patch**
-
-**Input:**
-```json
-{
- "patchText": "*** Begin Patch\n*** Update File: /home/alex/projects/payroll/docs/01-core-idea.md\n*** Move to: /home/alex/projects/payroll/docs/core-idea.md\n@@\n The product sits between customer payment collection and employer payout.\n \n-1. A customer makes a payment.\n-2. The platform receives the payment event directly, or receives trusted payment data from a partner.\n-3. A commission engine applies employer-defined rules.\n-4. The internal ledger allocates balances between employer and employee.\n-5. A safe portion of the employee's commission becomes available immediately.\n-6. The employee can cash out instantly, and later can also spend from a wallet or card.\n-7. The employer gets the remaining balance on a defined settlement schedule.\n-8. Both sides get visibility into earnings, payouts, and performance.\n+- A customer makes a payment.\n+- The platform receives the payment event directly, or receives trusted payment data from a partner.\n+- A commission engine applies employer-defined rules.\n+- The internal ledger allocates balances between employer and employee.\n+- A safe portion of the employee's commission becomes available immediately.\n+- The employee can cash out instantly, and later can also spend from a wallet or card.\n+- The employer gets the remaining balance on a defined settlement schedule.\n+- Both sides get visibility into earnings, payouts, and performance.\n@@\n-### 1. Payment collection or orchestration\n+### Payment collection or orchestration\n@@\n-### 2. Commission rules engine\n+### Commission rules engine\n@@\n-### 3. Ledger and balances\n+### Ledger and balances\n@@\n-### 4. Instant access rails\n+### Instant access rails\n@@\n-- Phase 1: instant bank transfer or `Pix` cash-out.\n-- Phase 2: stored balance inside the app.\n-- Phase 3: prepaid or debit card linked to the balance.\n+- Start with instant bank transfer or `Pix` cash-out.\n+- Later add stored balance inside the app.\n+- Later add a prepaid or debit card linked to the balance.\n@@\n-### 5. Employer analytics\n+### Employer analytics\n@@\n-### 6. Optional later financing layer\n+### Optional later financing layer\n*** Update File: /home/alex/projects/payroll/docs/02-brazil-market.md\n*** Move to: /home/alex/projects/payroll/docs/brazil-market.md\n@@\n Sequencia recomendada:\n \n-1. acesso ao que ja foi ganho e validado\n-2. liberacao conservadora de parte do saldo antes da liquidacao total\n-3. adiantamento com respaldo do empregador\n-4. so depois, se fizer sentido, credito com underwriting proprio\n+- acesso ao que ja foi ganho e validado\n+- liberacao conservadora de parte do saldo antes da liquidacao total\n+- adiantamento com respaldo do empregador\n+- so depois, se fizer sentido, credito com underwriting proprio\n*** Update File: /home/alex/projects/payroll/docs/03-market-memo.md\n*** Move to: /home/alex/projects/payroll/docs/market-memo.md\n*** Update File: /home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md\n*** Move to: /home/alex/projects/payroll/docs/positioning-and-landing-copy.md\n@@\n ## Headline options\n \n-1. Turn every sale into an instantly accessible commission.\n-2. Give sales teams instant access to earned commissions.\n-3. Real-time commissions for modern sales teams.\n-4. The fastest way to move from customer payment to salesperson payout.\n-5. Commission payouts, employer controls, and worker access in one platform.\n+- Turn every sale into an instantly accessible commission.\n+- Give sales teams instant access to earned commissions.\n+- Real-time commissions for modern sales teams.\n+- The fastest way to move from customer payment to salesperson payout.\n+- Commission payouts, employer controls, and worker access in one platform.\n@@\n ## Subhead options\n \n-1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.\n-2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.\n-3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.\n+- We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.\n+- Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.\n+- Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.\n@@\n ## CTA options\n \n-1. Talk to us about your commission workflow.\n-2. See how real-time commission payouts could work for your team.\n-3. Become a design partner.\n-4. Explore a commission infrastructure demo.\n+- Talk to us about your commission workflow.\n+- See how real-time commission payouts could work for your team.\n+- Become a design partner.\n+- Explore a commission infrastructure demo.\n*** Update File: /home/alex/projects/payroll/docs/05-roadmap-12-months.md\n*** Move to: /home/alex/projects/payroll/docs/year-one-roadmap.md\n@@\n-# 12-Month Roadmap\n+# Year-One Roadmap\n@@\n-## Phase 0: Foundation and partner design\n+## Foundation and partner design\n@@\n-## Phase 1: Core ledger and instant payout access\n+## Core ledger and instant payout access\n@@\n-## Phase 2: Analytics and stored balance\n+## Analytics and stored balance\n@@\n-## Phase 3: Card and retention tools\n+## Card and retention tools\n@@\n-## Phase 4: Scale features and controlled advance pilot\n+## Scale features and controlled advance pilot\n@@\n-1. prove employer demand for payment-linked commission automation\n-2. prove worker demand for instant access to eligible balances\n-3. prove safe operating rules around reversals and disputes\n-4. prove that analytics improves employer retention\n-5. prove that cards increase balance retention\n-6. only then test employer-backed advance products\n+- prove employer demand for payment-linked commission automation\n+- prove worker demand for instant access to eligible balances\n+- prove safe operating rules around reversals and disputes\n+- prove that analytics improves employer retention\n+- prove that cards increase balance retention\n+- only then test employer-backed advance products\n*** Update File: /home/alex/projects/payroll/AGENTS.md\n@@\n-## Key documents\n-\n-- `docs/01-core-idea.md` - canonical summary of the product and business model\n-- `docs/02-brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR\n-- `docs/03-market-memo.md` - competitor map, differentiation, and investor-style memo\n-- `docs/04-positioning-and-landing-copy.md` - messaging and homepage copy directions\n-- `docs/05-roadmap-12-months.md` - phased roadmap for the first year\n+## Key documents\n+\n+- `docs/core-idea.md` - canonical summary of the product and business model\n+- `docs/brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR\n+- `docs/market-memo.md` - competitor map, differentiation, and investor-style memo\n+- `docs/positioning-and-landing-copy.md` - messaging and homepage copy directions\n+- `docs/year-one-roadmap.md` - phased roadmap for the first year\n+- `docs/ideas-for-review.md` - review file for ideas not yet integrated into the core docs\n@@\n-- Keep `docs/02-brazil-market.md` in pt-BR.\n+- Keep `docs/brazil-market.md` in pt-BR.\n*** Add File: /home/alex/projects/payroll/README.md\n+# Payroll Planning Workspace\n+\n+Documentation-first workspace for a Brazil-first B2B2C fintech concept focused on payment-linked commissions, instant access to earned balances, and employer controls around payouts and analytics.\n+\n+## Document index\n+\n+- `docs/core-idea.md` - canonical summary of the product, operating model, and money flow\n+- `docs/brazil-market.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR\n+- `docs/market-memo.md` - market gap, competitor map, differentiation, and business model framing\n+- `docs/positioning-and-landing-copy.md` - messaging directions, landing-page copy, and narrative structure\n+- `docs/year-one-roadmap.md` - phased plan for the first year of product and partner execution\n+- `docs/ideas-for-review.md` - ideas from external conversations that are not yet part of the core docs\n+\n+## Suggested reading order\n+\n+- `docs/core-idea.md`\n+- `docs/brazil-market.md`\n+- `docs/market-memo.md`\n+- `docs/positioning-and-landing-copy.md`\n+- `docs/year-one-roadmap.md`\n+\n+## Notes\n+\n+- Write in English by default; keep `docs/brazil-market.md` in pt-BR.\n+- The repository currently holds strategy and planning documents, not production code.\n+- Session transcripts live under `sessions/`.\n*** Add File: /home/alex/projects/payroll/docs/ideas-for-review.md\n+# Ideas For Review\n+\n+This file captures ideas raised in external conversations that are not yet integrated into the main planning docs. It is a parking lot for later review, not an approved roadmap.\n+\n+## Potential additions\n+\n+### Employer availability controls\n+\n+- Let employers configure what share of earned commission becomes available immediately.\n+- Support policy rules by role, channel, product, or refund-risk profile.\n+- Add employer-set caps, waiting windows, and override rules for cash-out eligibility.\n+\n+### Clearer balance messaging\n+\n+- Make the employee-facing UX explicit: `earned` now, `available` later, with concrete wording such as `earned now, withdrawable in X days`.\n+- Pair that messaging with visible explanations for employer policy, refund risk, and dispute timing.\n+\n+### Deeper analytics modules\n+\n+- Show progress toward target or quota at the individual employee level.\n+- Track refund or chargeback rates by employer, location, channel, or seller.\n+- Trigger alerts when employee performance drops or when refund behavior starts affecting availability.\n+- Consider a premium analytics tier only after the core workflow proves valuable.\n+\n+### Pricing and economics to evaluate\n+\n+- Test employer pricing tiers based on payment volume, workflow complexity, or payout usage.\n+- Define the economics of employer-backed advances, including whether part of the fee is shared with the employer.\n+- If retained-balance incentives are explored later, keep them aligned with partner-held custody and avoid making float the primary value case.\n+\n+## Ideas raised but not aligned with the current thesis\n+\n+- Direct custody or wording that implies customer funds sit in the company account.\n+- Float as an early core revenue driver.\n+- Using retained funds to build a lending business before the ledger, controls, and reversal data are mature.\n+- Making advances an early flagship feature instead of a later employer-backed extension.\n*** End Patch"
-}
-```
-
-**Output:**
-```
-Success. Updated the following files:
-M docs/core-idea.md
-M docs/brazil-market.md
-M docs/market-memo.md
-M docs/positioning-and-landing-copy.md
-M docs/year-one-roadmap.md
-M AGENTS.md
-A README.md
-A docs/ideas-for-review.md
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 9.4s)
-
-_Thinking:_
-
-**Deciding on updates**
-
-I’m considering whether I need to update sessions to maintain transcript integrity. It’s worth noting that old references can stay in `sessions/` since the transcripts are preserved. I need to decide on this. Additionally, I want to search for any numbered list patterns in the documentation and old filename references throughout the repository. Once I gather all that information, I can decide if updates are necessary. Alright, let’s proceed with the searches!
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "^[0-9]+\\. ",
- "path": "/home/alex/projects/payroll/docs",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-No files found
-```
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "^#{1,6} .*?[0-9]+[\\.:]",
- "path": "/home/alex/projects/payroll/docs",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-No files found
-```
-
-**Tool: grep**
-
-**Input:**
-```json
-{
- "pattern": "docs/0[1-5]-|01-core-idea\\.md|02-brazil-market\\.md|03-market-memo\\.md|04-positioning-and-landing-copy\\.md|05-roadmap-12-months\\.md",
- "path": "/home/alex/projects/payroll",
- "include": "*.md"
-}
-```
-
-**Output:**
-```
-Found 26 matches
-/home/alex/projects/payroll/sessions/session-ses_2f39.md:
- Line 6235: I should mention that no edits have been made, which is good. I’m considering using a heading like **Plan** to be more helpful. Maybe I could add sections like **Deliverables** and **Default Choices**, each with 4-6 concise bullet points. I'll make sure there are no nested bullets, and ensure each section remains clear. Also, the file references should be clickable, like `session-ses_2fe5.md` and `docs/01-core-idea.md`. That sounds solid!
- Line 6246: - `docs/01-core-idea.md` — the core parts of the idea: problem, solution, money flow, product layers, revenue model, phased expansion, key risks.
- Line 6247: - `docs/02-brazil-market.md` — Brazil-specific thesis: why Brazil first, `Pix`, `vales`, target verticals, partner types, local regulatory/operational constraints, GTM.
- Line 6248: - `docs/03-market-memo.md` — investor-style memo: market gap, competitor map, wedge, differentiation, why now, business model.
- Line 6249: - `docs/04-positioning-and-landing-copy.md` — sharper messaging: headline options, subheads, value props, employer/employee language, CTA copy.
- Line 6250: - `docs/05-roadmap-12-months.md` — phased roadmap: core ledger + `Pix`, analytics + stored balance, cards, then credit/scale.
- Line 6253: - Write `docs/01-core-idea.md` first so the rest share one consistent framing.
- Line 6254: - Derive `docs/02-brazil-market.md` and `docs/03-market-memo.md` from that foundation.
- Line 6255: - Use those to produce `docs/04-positioning-and-landing-copy.md`.
- Line 6256: - Finish with `docs/05-roadmap-12-months.md` so the roadmap reflects the finalized narrative.
- Line 6260: - Founder/investor tone for `docs/03-market-memo.md`, more operator/practical tone for `docs/02-brazil-market.md`.
- Line 6263: If you want, the one choice worth deciding before execution is whether `docs/02-brazil-market.md` should stay in English or be written in Portuguese; otherwise I’d proceed with the defaults above once write mode is available.
- Line 6428: I'm thinking about how to structure the documentation, organizing it with specific files like "01-core-idea.md" and "02-brazil-market.md." I want to make sure it’s solid but not too verbose. Maybe a docs index could be helpful but I’m not sure it’s necessary. I should probably create the "docs" directory first and then apply patches for the new files. The AGENTS.md should give context about the project, everything from its purpose to the target audience. I’ll need to ensure content is consistent throughout!
- Line 6657: I’m considering a multi-entity forecast for partner expansion with a potential employer-backed advance general release. I've outlined metrics like commission GMV, conversion rates, and payout latency, but I shouldn’t go beyond certain scopes, such as standalone consumer lending or full payroll. I might create `docs/01-core-idea.md` to avoid too much duplication while ensuring it serves as a clear internal summary. I need to include a clear money flow block in that document and keep it concise, around 700 lines. Let's build this carefully!
- Line 6664: "patchText": "*** Begin Patch\n*** Add File: /home/alex/projects/payroll/docs/01-core-idea.md\n+# Core Idea\n+\n+## One-line thesis\n+\n+A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.\n+\n+## The problem\n+\n+### Employers\n+\n+- Commission calculation is often manual, delayed, and hard to audit.\n+- Sales teams ask for informal advances when payroll cycles lag behind real sales activity.\n+- Finance teams struggle to forecast commission liability and reconcile payouts.\n+- Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.\n+\n+### Employees\n+\n+- A sale can happen today, but the commission may not be usable for days or weeks.\n+- Early access to money often depends on asking for an informal advance.\n+- There is rarely a clear view of what has been earned, what is available, and what is still pending.\n+\n+## The product\n+\n+The product sits between customer payment collection and employer payout.\n+\n+1. A customer makes a payment.\n+2. The platform receives the payment event directly, or receives trusted payment data from a partner.\n+3. A commission engine applies employer-defined rules.\n+4. The internal ledger allocates balances between employer and employee.\n+5. A safe portion of the employee's commission becomes available immediately.\n+6. The employee can cash out instantly, and later can also spend from a wallet or card.\n+7. The employer gets the remaining balance on a defined settlement schedule.\n+8. Both sides get visibility into earnings, payouts, and performance.\n+\n+## Core product layers\n+\n+### 1. Payment collection or orchestration\n+\n+- Accept customer payments directly, or integrate with the employer's processor.\n+- Use payment events as the source of truth for commission creation.\n+\n+### 2. Commission rules...
- Line 6671: A docs/01-core-idea.md
- Line 6672: A docs/02-brazil-market.md
- Line 6673: A docs/03-market-memo.md
- Line 6674: A docs/04-positioning-and-landing-copy.md
- Line 6675: A docs/05-roadmap-12-months.md
- Line 6697: - Added the core concept doc in `docs/01-core-idea.md`
- Line 6698: - Added the Brazil-specific thesis in pt-BR in `docs/02-brazil-market.md`
- Line 6699: - Added the investor-style market memo in `docs/03-market-memo.md`
- Line 6700: - Added positioning and landing copy in `docs/04-positioning-and-landing-copy.md`
- Line 6701: - Added the phased first-year plan in `docs/05-roadmap-12-months.md`
- Line 6716: 3. I can turn this into a simple landing page or pitch deck structure based on `docs/04-positioning-and-landing-copy.md`
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 8.3s)
-
-_Thinking:_
-
-**Finalizing document details**
-
-I need to produce the final answer, but first, I should verify the contents of the files and update the to-do list. I'll quickly check the README and ideas-for-review. Also, inspecting AGENTS might help. The user asked to drop the numbering in documents, but since session transcripts still mention old names, I don't think we need to update them. I should verify the documents for accuracy and readability, especially README and ideas files. Let's get started!
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/README.md",
- "offset": 1,
- "limit": 120
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/README.md
-file
-1: # Payroll Planning Workspace
-2:
-3: Documentation-first workspace for a Brazil-first B2B2C fintech concept focused on payment-linked commissions, instant access to earned balances, and employer controls around payouts and analytics.
-4:
-5: ## Document index
-6:
-7: - `docs/core-idea.md` - canonical summary of the product, operating model, and money flow
-8: - `docs/brazil-market.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR
-9: - `docs/market-memo.md` - market gap, competitor map, differentiation, and business model framing
-10: - `docs/positioning-and-landing-copy.md` - messaging directions, landing-page copy, and narrative structure
-11: - `docs/year-one-roadmap.md` - phased plan for the first year of product and partner execution
-12: - `docs/ideas-for-review.md` - ideas from external conversations that are not yet part of the core docs
-13:
-14: ## Suggested reading order
-15:
-16: - `docs/core-idea.md`
-17: - `docs/brazil-market.md`
-18: - `docs/market-memo.md`
-19: - `docs/positioning-and-landing-copy.md`
-20: - `docs/year-one-roadmap.md`
-21:
-22: ## Notes
-23:
-24: - Write in English by default; keep `docs/brazil-market.md` in pt-BR.
-25: - The repository currently holds strategy and planning documents, not production code.
-26: - Session transcripts live under `sessions/`.
-
-(End of file - total 26 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs/ideas-for-review.md",
- "offset": 1,
- "limit": 200
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs/ideas-for-review.md
-file
-1: # Ideas For Review
-2:
-3: This file captures ideas raised in external conversations that are not yet integrated into the main planning docs. It is a parking lot for later review, not an approved roadmap.
-4:
-5: ## Potential additions
-6:
-7: ### Employer availability controls
-8:
-9: - Let employers configure what share of earned commission becomes available immediately.
-10: - Support policy rules by role, channel, product, or refund-risk profile.
-11: - Add employer-set caps, waiting windows, and override rules for cash-out eligibility.
-12:
-13: ### Clearer balance messaging
-14:
-15: - Make the employee-facing UX explicit: `earned` now, `available` later, with concrete wording such as `earned now, withdrawable in X days`.
-16: - Pair that messaging with visible explanations for employer policy, refund risk, and dispute timing.
-17:
-18: ### Deeper analytics modules
-19:
-20: - Show progress toward target or quota at the individual employee level.
-21: - Track refund or chargeback rates by employer, location, channel, or seller.
-22: - Trigger alerts when employee performance drops or when refund behavior starts affecting availability.
-23: - Consider a premium analytics tier only after the core workflow proves valuable.
-24:
-25: ### Pricing and economics to evaluate
-26:
-27: - Test employer pricing tiers based on payment volume, workflow complexity, or payout usage.
-28: - Define the economics of employer-backed advances, including whether part of the fee is shared with the employer.
-29: - If retained-balance incentives are explored later, keep them aligned with partner-held custody and avoid making float the primary value case.
-30:
-31: ## Ideas raised but not aligned with the current thesis
-32:
-33: - Direct custody or wording that implies customer funds sit in the company account.
-34: - Float as an early core revenue driver.
-35: - Using retained funds to build a lending business before the ledger, controls, and reversal data are mature.
-36: - Making advances an early flagship feature instead of a later employer-backed extension.
-
-(End of file - total 36 lines)
-
-```
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/docs",
- "offset": 1,
- "limit": 50
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/docs
-directory
-
-brazil-market.md
-core-idea.md
-ideas-for-review.md
-market-memo.md
-positioning-and-landing-copy.md
-year-one-roadmap.md
-
-(6 entries)
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 3.7s)
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "completed",
- "priority": "medium"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Search repo for references to numbered doc filenames and determine rename scope",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Rename doc files to drop numeric prefixes and update references",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Draft a separate review file with ideas not yet captured in docs",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Create a repository README that indexes the documents",
- "status": "completed",
- "priority": "high"
- },
- {
- "content": "Verify file moves and new docs, then summarize changes",
- "status": "completed",
- "priority": "medium"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 17.6s)
-
-_Thinking:_
-
-**Finalizing document changes**
-
-I need to compile a final response for the user. They requested that we drop numbering from the documents, and we’ve made changes to filenames and any internal numbering. I checked for any remaining numbered headings and checked with grep—there are none left.
-
-The only references still using old names are in `sessions/session-ses_2f39.md` since it’s a transcript and hasn’t been edited. Also, no tests were run on these edits because we’re focusing on the documentation. Lastly, I should note that `AGENTS.md` was updated as well.
-
-_Thinking:_
-
-**Explaining changes**
-
-I might consider starting with a header like "Done," but I’m not entirely sure yet. I think it would be helpful to lead with a quick explanation of the changes made, followed by more detailed information. Since these updates revolve around code and documents, highlighting what changed, where, and why could provide clarity. It's essential that I present this clearly so the user can easily understand the updates.
-
-_Thinking:_
-
-**Document updates summary**
-
-I’ve updated the repository to ensure the documents are unnumbered. I added a top-level `README.md` as an index with descriptions, reading order, and language details. I also created `docs/ideas-for-review.md` for ideas not yet included in the main docs, like employer availability controls and clearer messaging.
-
-I renamed document files to remove numeric prefixes and dropped numbering from headings and lists. There's just one remaining old reference in `sessions/session-ses_2f39.md`, which I didn’t edit since it’s a transcript.
-
-_Thinking:_
-
-**Planning next steps**
-
-That sounds relevant! I think I should outline some immediate next steps.
-
-First, I can fold items from `docs/ideas-for-review.md` into the core documentation. This will help integrate those ideas more effectively.
-
-I might consider what other steps to take after that, but right now, focusing on merging those items seems like a solid plan. I want to ensure everything flows well in the core docs as I make these changes.
-
-Updated the repo so the docs are unnumbered, the repo has an index `README`, and the missing ideas are parked in a separate review file.
-
-- Added `README.md` as the top-level index for the workspace, with the main docs, reading order, and repo notes.
-- Added `docs/ideas-for-review.md` to capture ideas not yet integrated into the core plan, including employer availability controls, clearer `earned`/`available` messaging, deeper analytics, and pricing / advance-economics questions.
-- Renamed the main docs to drop numeric prefixes:
- - `docs/core-idea.md`
- - `docs/brazil-market.md`
- - `docs/market-memo.md`
- - `docs/positioning-and-landing-copy.md`
- - `docs/year-one-roadmap.md`
-- Removed numbering inside the docs where it was used in headings and list items, and updated `AGENTS.md` to reference the new filenames plus `docs/ideas-for-review.md`.
-- Verified there are no old numbered doc references left in the active docs; the only remaining old names are in `sessions/session-ses_2f39.md`, which I left untouched as a transcript.
-
-If you want, I can next:
-1. Fold selected items from `docs/ideas-for-review.md` into the main docs
-2. Tighten the README into a more investor-facing or collaborator-facing index
-
----
-
diff --git a/sessions/session-ses_2f39.md b/sessions/session-ses_2f39.md
deleted file mode 100644
index 703a82e..0000000
--- a/sessions/session-ses_2f39.md
+++ /dev/null
@@ -1,6719 +0,0 @@
-# Instant commission payouts fintech thesis (Brazil focus)
-
-**Session ID:** ses_2f39164d0ffend7HDsg8OkqEbd
-**Created:** 3/20/2026, 6:07:48 PM
-**Updated:** 3/20/2026, 6:26:13 PM
-
----
-
-## User
-
-Looking at this @session-ses_2fe5.md
-Does a company like this exist?
-
----
-
-## Assistant (Plan · gpt-5.4 · 15.8s)
-
-_Thinking:_
-
-**Analyzing company existence**
-
-The user is asking about the company based on a specific file they provided. We need to analyze whether such a company exists, and it’s likely I’ll need to do some research using webfetch or GitHub for context. I think adjacent companies may be out there, but the exact match might not exist. Since traditional search engines might not be an option here, I could explore navigating with a browser for broader research.
-
-_Thinking:_
-
-**Exploring company research**
-
-I think I need to use webfetch on company websites I already know from the file, like DailyPay, Caju, and Xerpay. The user’s asking if companies like these exist, so I’ll need to assess if there are companies combining commission payouts with instant access, wallets/cards, and analytics. From what I recall, adjacent companies may exist, such as Clair or Rain. I’ll confirm names and specifics using webfetch and possibly explore further with a research task. A well-researched plan is essential!
-
-_Thinking:_
-
-**Considering research options**
-
-The user has asked a direct question, so I think I can provide an answer. It might be helpful to do some research using webfetch or a search engine if needed. I should avoid asking the user unnecessary questions. I also need to think about context management, ensuring the conversation stays concise since I only plan to use one tool. It might be wise to check the file for mentions of comparable companies, specifically around line 688. I could answer based on my knowledge that while similar pieces exist, an exact end-to-end solution may not.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.dailypay.com/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
- On-Demand Pay Platform - DailyPay
-
-[Skip to main content](#content)
-
-Are you an employee? [Log in or sign up](https://dailypay.app.link/WaMojfWFLTb)
-
-[Skip to main content](#content)
-
-[](/)
-
-[](/)
-
-- Employers
-
- [
-
- DailyPay Overview
-
- On-Demand Pay — also known as earned wage access — gives employees access to their earned pay before payday. DailyPay is your key to improving recruitment, retention, motivation and productivity.
-
- ](/earned-wage-access-platform/)[
-
- Why DailyPay
-
- When your employees have greater control over their finances, your business wins too.
-
- ](/benefits/)[
-
- Clients
-
- DailyPay partners with industry leaders across HCM and payroll for a seamless experience.
-
- ](/clients/)[
-
- Integrations
-
- DailyPay integrates with 180+ HCM, payroll and time management systems to deliver industry-leading EWA to millions of users.
-
- ](/integrations/)
-
- Industries
-
- [
-
- Overview
-
- While each industry has to deal with unique economic factors and different customer bases, one constant is the employee. Learn how to support them with On-Demand Pay.
-
- ](/industries/)
-
- - [Hospitals & Healthcare](/industries/healthcare/)
- - [Grocers & Supermarkets](/industries/grocers-supermarkets/)
- - [Retail](/industries/retail/)
- - [Call & Contact Centers](/industries/call-contact-centers/)
- - [Restaurants & QSR](/industries/qsr-restaurants/)
- - [Manufacturing](/industries/manufacturing/)
- - [Travel & Hospitality](/industries/travel-hospitality/)
- - [Public Sector](/industries/public-sector/)
- - [Franchise](/industries/franchise/)
-
- See the DailyPay difference [Let's Talk](/demo/)
-
- Featured resources
-
- [
-
- 
-
- Education Series
-
- All You Need to Know About On-Demand Pay
-
-
-
- ](/on-demand-pay/)
-
- [
-
- 
-
- Case Study
-
- DailyPay: The Benefit Duracell’s Employees Asked for by Name
-
-
-
- ](/resource-center/case-studies/duracell-benefit-employees-asked-for/)
-
- [
-
- 
-
- Case Study
-
- Offering DailyPay Helped Adecco Improve Retention in the Staffing Industry
-
-
-
- ](/resource-center/case-studies/adecco-standing-out-in-the-staffing-industry-with-dailypay/)
-
-- Solutions
-
- Platform & Features
-
- [ DailyPay Platform
-
- Industry-leading On-Demand Pay.](/earned-wage-access-platform/) [ Small Business New
-
- On-Demand Pay for businesses under 500 employees.](/on-demand-pay-small-business/)
-
- [ DailyPay Visa® Prepaid Card
-
- Reach even more employees with On-Demand Pay.](/dailypay-card/) [ Cycle
-
- Easily disburse off-cycle pay.](/cycle/) [ Tips
-
- Real-time digital tips access.](/real-time-digital-tips-access-platform/) [ Perks New
-
- Employ financial benefits with curated discounts and deals on life’s biggest expenses](/perks/)
-
- By initiative
-
- [
-
- Implement On-Demand Pay
-
- On-Demand Pay improves employee retention and recruitment.
-
- ](/earned-wage-access/)
-
- [
-
- Reduce Employee Turnover
-
- How much does turnover cost your company?
-
- ](/resource-center/employee-turnover/)
-
- [
-
- Improve Employee Financial Wellness
-
- How does employee financial wellness impact your bottom line?
-
- ](/resource-center/employee-financial-wellness/)
-
- [
-
- Improve Employee Retention
-
- Experience cost savings and higher workplace morale.
-
- ](/resource-center/employee-retention/)
-
- [
-
- Increase Employee Engagement
-
- Boost productivity and revenue.
-
- ](/employee-engagement-strategies/)
-
- [Explore all Integrations](/integrations/) Our On-Demand Pay solution integrates with payroll and time management systems.
-
- Featured resources
-
- [
-
- 
-
- Turnover Calculator
-
- How much is turnover costing your company?
-
-
-
- ](/employee-turnover-calculator/)
-
- [
-
- 
-
- whitepaper
-
- DailyPay Tops List as #1 Adopted Financial Wellness Benefit
-
-
-
- ](/surveys/top-financial-wellness-benefit/)
-
- [
-
- 
-
- Thought Leadership
-
- How Can an On-Demand Pay Platform Help Your Business?
-
-
-
- ](/earned-wage-access/)
-
-- Our Partners
-
- [
-
- Partners Overview
-
- Work with DailyPay to implement the most trusted solutions in On-Demand Pay that work best for your clients and their employees.
-
- ](/marketplace/)
-
- [
-
- Human Capital Management
-
- ](/marketplace/#ct-tabs)
-
- [
-
- Workforce Management
-
- ](/marketplace/#ct-tabs)
-
- [
-
- Banks & Financial Institutions
-
- ](/marketplace/#ct-tabs)
-
- [
-
- DailyPay Built InTM New
-
- The easiest way for HCM partners to integrate EWA into their platform.
-
- ](/marketplace/ewa-payroll-builtin/)
-
- Featured Partner
-
- [
-
- 
-
- DailyPay: The Preferred On-Demand Pay Solution for Workday Customers
-
-
-
- ](/workday/)
-
-- Resources
-
- Learn
-
- [
-
- Blog
-
- ](/resource-center/blog/)[
-
- Case Studies
-
- ](/resource-center/case-studies/)[
-
- Guides
-
- ](/resource-center/ebooks/)[
-
- Podcasts
-
- ](/resource-center/podcasts/)[
-
- Webinars
-
- ](/resource-center/webinars/)
-
- [ On-Demand Pay Education Series
-
- Learn how to get started with On-Demand Pay.](/on-demand-pay/) [ DailyPay Certification Program
-
- Free courses to earn EWA certification & SHRM credit.](/certification-program/)
-
- Company
-
- - [About Us](/about-us/)
- - [Impact](/impact/)
- - [Awards & Recognition](/awards/)
- - [Press Center](/press-center/)
-
- [Resource Center](/resource-center/) Our library of On-Demand Pay thought leadership.
-
- Featured resources
-
- [
-
- 
-
- Turnover Calculator
-
- How much is turnover costing your company?
-
-
-
- ](/employee-turnover-calculator/)
-
- [
-
- 
-
- Blog
-
- How Employee Engagement Impacts Your Bottom Line
-
-
-
- ](/resource-center/blog/the-three-levels-of-employee-engagement-and-how-they-impact-your-bottom-line/)
-
- [
-
- 
-
- Blog
-
- What is a Paycheck Advance and Why You Should Avoid Them
-
-
-
- ](/resource-center/blog/the-three-levels-of-employee-engagement-and-how-they-impact-your-bottom-line/)
-
-- [For Employees](https://get.dailypay.com/?utm_source=wwwheader&utm_medium=crossdomain)
-
-### For Employees
-
-Ready to see your available balance?
-
-[Log In](https://dailypay.app.link/wpRH63ZlyTb) [Sign Up](https://dailypay.app.link/vYyj0iSlyTb)
-
-[Get a Demo](/demo/)
-
-Search Icon A magnifying glass representing search
-
-[](/)
-
-Search
-
-Close Search Popup Close the search popup
-
-popular searches
-
-[earned wage access](/?s=earned+wage+access) [On-Demand Pay](/?s=On-Demand+Pay) [improve employee retention](/?s=improve+employee+retention) [employee financial wellness](/?s=employee+financial+wellness) [reduce turnover](/?s=reduce+turnover) [Increase employee engagement](/?s=Increase+employee+engagement)
-
-[Log In](https://app.dailypay.com/login?utm_source=wwwlogin&utm_medium=crossdomain) [Get a Demo](/demo/)
-
- Modern HCM and payroll providers thrive on DailyPay partnerships. [Learn More](/marketplace/)
-
-# Hard Work
-Pays
-Off
-On the Daily
-
-Pay Your Employees On Their Schedule With On-Demand Pay
-
-DailyPay provides an industry-leading On-Demand Pay platform that gives your employees access to their pay when they want it.
-
-[Get a Demo](/demo/)
-
- 
-
-
-
-
-
-
-
-[DailyPay’s Platform](/earned-wage-access-platform/ ) helps employers recruit, retain, and engage employees. In turn, employees can build, earn, and grow their wealth. We are transforming how the world gets paid so every worker can meet life’s moments with confidence.
-
-[Explore Platform](/overview/)
-
-  
-
-Trusted by leading companies
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-integration partners
-
-
-
-
-
-
-
-
-
-
-
-## Recruit, Retain,
-and Engage Employees
-
-DailyPay transforms employers into industry leaders by revolutionizing the way employees access their pay.
-
-[See how we stand out](/benefits/)
-
-[](https://iframe.mediadelivery.net/embed/208304/c33bf779-e863-45e3-963d-143df312a8b6?autoplay=true&loop=true&muted=true&preload=true&responsive=true)
-
-
-
-### Help Them Build, Earn, and Grow Their Wealth
-
-DailyPay’s financial wellness empowers employees to take control of their earnings.
-
-[See how it works for employees](https://get.dailypay.com/)
-
-## Recognized as the Industry Leader
-
-We’re proud to have been honored with the following [awards](/awards/).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-successful implementation
-
-## Commitment to Employee Adoption
-
-The DailyPay Solution starts by seamlessly and securely integrating with payroll systems to leave little to no added work for payroll teams. From there, collaborative services work with you on technical implementation, customized launch strategy, employee activation, client onboarding, training, marketing and more.
-
-
-
-**Simple Implementation**
-
-
-
-**No building or retooling**
-
-
-
-**Ready fast**
-
-## The Insights You Need, When You Need Them
-
-Read about the latest research, events and more involving DailyPay and On-Demand Pay and how we’re working to build a path towards modern pay solutions for all.
-
-[Explore all resources](/resource-center/)
-
-[
-
-
-
-DailyPay Selected as Workday's Strategic Partner for On-Demand Pay
-
-The companies are now offering a more connected experience for joint customers that empowers employees with access to their earnings on their own schedule, when they need it most. The Strategic Partnership will help companies recruit, retain, and engage employees.
-
-Learn more
-
-](/press-center/press-releases/workday-and-dailypay-form-strategic-partnership-to-bring-on-demand-pay-to/)
-
-## Latest
-
-[
-
-
-
-Report
-
-**DailyPay Tops List as #1 Adopted Financial Wellness Benefit**
-
-
-
-](/surveys/top-financial-wellness-benefit/)
-
-[
-
-
-
-Blog
-
-**How Improved Financial Wellness Can Help Employers**
-
-
-
-](https://www.dailypay.com/resource-center/blog/improve-employee-financial-wellness/)
-
-[
-
-
-
-BLOG
-
-**Empower Your Workforce With Real-Time Digital Access Through DailyPay Tips**
-
-
-
-](https://www.dailypay.com/resource-center/blog/how-restaurants-can-instantly-disburse-tips-in-real-time/)
-
-[
-
-
-
-BLOG
-
-**The Hidden Benefits of On-Demand Pay for Employers**
-
-
-
-](https://www.dailypay.com/resource-center/blog/hidden-benefits-of-on-demand-pay-employers/)
-
-[
-
-
-
-Blog
-
-**How Financial Wellness Improves Employee Engagement**
-
-
-
-](https://www.dailypay.com/resource-center/blog/financial-wellness/)
-
-[
-
-
-
-BLOG
-
-**Attract and Retain the Next Generation of Government Workers With Financial Wellness Benefits**
-
-
-
-](https://www.dailypay.com/resource-center/blog/attract-public-sector-employees-ewa/)
-
-
-
-### Business Leaders Count On DailyPay
-
-“As a result of implementing DailyPay, we now have 58% less turnover in the first two weeks on the job among our agents who are using DailyPay compared to those who are not using DailyPay.”
-
-Rob Schultz
-
-SVP of HR & Compliance for DialAmerica
-
-
-
-[Read the case study](https://www.dailypay.com/resource-center/case-studies/case-study-dialamerica/)
-
-### Business Leaders Count On DailyPay
-
-“We implemented DailyPay and saw a 25% increase in operating hours… we’re starting not only to see it stabilize, but improve.”
-
-Darin Harris
-
-CEO of Jack in the Box
-
-
-
-[Read the case study](https://www.fool.com/earnings/call-transcripts/2021/11/23/jack-in-the-box-inc-jack-q4-2021-earnings-call-tra/)
-
-### Business Leaders Count On DailyPay
-
-“These efforts have resulted in better seasonal hiring results, which was one of our main goals in rolling out this program. We have also seen an increase in retention rates, with turnover currently at 36% for non-DailyPay users and 22% for DailyPay users.”
-
-Dawn Ehrhart
-
-SVP of Shared Service Operations for the Americas for The Adecco Group
-
-
-
-[Read the case study](https://www.dailypay.com/resource-center/case-studies/adecco-standing-out-in-the-staffing-industry-with-dailypay/)
-
-### Business Leaders Count On DailyPay
-
-“Statistics show that 52% of our associates who use DailyPay use it for bills, 13% use it for transit and 8% use it for food.”
-
-Jake Bell
-
-CEO of Christian Horizons
-
-
-
-[Read the case study](https://www.dailypay.com/resource-center/case-studies/dailypay-and-christian-horizons-a-strong-partnership-through-times-of-crisis/)
-
-### Business Leaders Count On DailyPay
-
-“We couldn’t be happier with the team we work with at DailyPay. Their people are their true differentiator against other On-Demand Pay providers.”
-
-Taylor Leevers
-
-Special Projects Manager for Leevers Supermarkets, Inc.
-
-
-
-[Read the case study](https://www.dailypay.com/resource-center/case-studies/dailypay-leevers-supermarkets-partners/)
-
-
-
-
-
-
-
-
-
-
-
-## See Why Top Companies Choose DailyPay
-
-[Let's Talk](/demo/)
-
-
-
-**Empowering for Employees**
-
-Greater financial control with access to up to 100% of their DailyPay Balance to meet the challenges of unexpected financial disruptions.
-
----
-
-Improved planning with visibility to withdrawals and earned pay in one easy-to-use app.
-
----
-
-No need for a pre-existing checking or savings account.
-
-
-
-**Simple and Secure for Employers**
-
-No change to payroll processes — DailyPay compliantly handles it all.
-
----
-
-Seamless integration with HCM, payroll, banking and benefit applications.
-
----
-
-Enterprise-grade platform that keeps data private and the service running so it's always there when your employees need it.
-
-[](/)
-
-DailyPay HQ
-
-55 Water Street New York, NY 10041
-
-[Contact us](/contact/)
-
-- [](https://www.glassdoor.com/Overview/Working-at-DailyPay-EI_IE1197210.11,19.htm)
-- [](https://www.facebook.com/dailypay)
-- [](https://twitter.com/dailypay)
-- [](https://www.linkedin.com/company/dailypay/)
-- [](https://www.instagram.com/dailypay/)
-- [](https://www.youtube.com/channel/UCOHcuqx2v4Yqpm1bdt1AMWA)
-
-- ##### Company
-
- - ##### Company 1
-
- - [About Us](/about-us/)
- - [Awards & Recognition](/awards/)
- - [Impact](/impact/)
- - [Security](/security/)
- - [Compliance](/en-us/legal/compliance/)
- - [Press Center](/press-center/)
- - [Careers](/careers)
- - [DailyPay Pioneers](/pioneers/)
-- ##### For Employers
-
- - [Overview](/overview/)
- - [Why DailyPay](/benefits/)
- - [Clients](/clients/)
- - [Industries](/industries/)
- - [Channel Partners](/marketplace/)
- - [Integrations](/integrations//)
-- ##### Platform & Features
-
- - [DailyPay Platform](/earned-wage-access-platform/)
- - [DailyPay Visa® Prepaid Card](/dailypay-card/)
- - [Cycle](/cycle/)
- - [Reward](/reward/)
- - [Tips](/real-time-digital-tips-access-platform/)
-- ##### Resources
-
- - [Blog](/resource-center/blog/)
- - [On-Demand Pay Education Series](/on-demand-pay/)
- - [Employee Turnover Calculator](/employee-turnover-calculator/)
- - [Integrations](/integrations/)
- - [Employee Retention](/resource-center/employee-retention/)
- - [On-Demand Pay](/resource-center/how-can-earned-wage-access-help-your-business/)
- - [Resource Center](/resource-center/)
- - [Research & Statistics](/stats/)
-- [For Employees](https://get.dailypay.com/?utm_source=wwwfooter&utm_medium=crossdomain)
-
- EN
-
-- [English (EN)](https://dailypay.ca/en-ca/)
-- [Français (FR)](https://dailypay.ca/fr-ca/)
-
----
-
-- [English (EN)](https://dailypay.co.uk)
-
----
-
-- [English (EN)](https://dailypay.com)
-
-
-
-For Employees
-
-[
-
-
-
-
-
-visit get.dailypay.com
-
-](https://get.dailypay.com/?utm_source=wwwfooter&utm_medium=crossdomain)
-
-Get the DailyPay app
-
- [](https://apps.apple.com/us/app/dailypay-on-demand-pay/id1399085077)[](https://play.google.com/store/apps/details?id=com.DailyPay.DailyPay&hl=en_CA&gl=US)
-
-[](/)
-
-- [](https://www.glassdoor.com/Overview/Working-at-DailyPay-EI_IE1197210.11,19.htm)
-- [](https://www.facebook.com/dailypay)
-- [](https://twitter.com/dailypay)
-- [](https://www.linkedin.com/company/dailypay-inc/)
-- [](https://www.instagram.com/dailypay/)
-- [](https://www.youtube.com/channel/UCOHcuqx2v4Yqpm1bdt1AMWA)
-
-- [© DailyPay 2026](/)
-- [Privacy](/en-us/legal/privacy/)
-- [Do Not Sell or Share My Personal Information](/legal/cookie-declaration/)
-- [Consumer Privacy Notice](https://assets.dailypay.com/wp-content/uploads/dailypay-glba-consumer-notice.pdf)
-- [Accessibility](/accessibility/)
-- [Terms of Service](/en-us/legal/terms-of-service/)
-- [OSS Attribution](/legal/open-source-software-attribution)
-- [Program Terms](/en-us/legal/program-terms/)
-- [Status](https://status.dailypay.com/)
-
-App Store, Apple Pay, and the Apple Logo are trademarks of Apple Inc. Google, Google Play, and Google Pay are trademarks of Google LLC. Samsung Pay is a registered trademark of Samsung Electronics Co., Ltd. All other trademarks shown are the property of their respective owners.
-
-The DailyPay Visa® Prepaid Card is issued by The Bancorp Bank, N.A., Member FDIC, pursuant to a license from Visa U.S.A. Inc. and can be used everywhere Visa debit cards are accepted.
-
-Your funds are FDIC insured through The Bancorp Bank, N.A., Member FDIC. DailyPay is not FDIC-insured. Deposit insurance coverage only protects against failure of The Bancorp Bank, N.A.
-
-For residents in the state of Connecticut, these services may be restricted or unavailable due to restrictions in your state on earned wage access. Please see this [Help Center](https://help.dailypay.com/hc/en-us/articles/23630960763411-I-live-in-CT-How-do-I-use-DailyPay?utm_source=Iterable&utm_medium=email&utm_campaign=DPC_DPC_Inactive%252FPost_Term_-_BF%252FCM_S%2526amp%253BG_-_Email_2_-_111524.html_-12345) article for further information.
-
-DailyPay, LLC's Earned Wage License Number in Nevada is EWA00004.
-
-DailyPay, LLC's Earned Wage License Number in Wisconsin is 2587396EWA.
-
-DailyPay, LLC's [NMLS](https://www.nmlsconsumeraccess.org/) ID is 2587396.
-
-
-
-### Evaluating On-Demand Pay Vendors?
-
-Learn the basics of On-Demand Pay, how to evaluate potential vendors, and the On-Demand Pay features your company needs to ensure success.
-
-Download the Guide
-
-## Subscribe Form
-
-Please tell us a little bit about yourself, so we know who and where to send our eBook to.
-
-Cancel
-
-### Thank You!
-
-Check your email in the next few minutes for our eBook, **On-Demand Pay 101**.
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.branchapp.com/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
-Fast Payments for Any Workforce | Branch
-
-[](/)
-
-Solutions
-
-[
-
-Pay Your Way
-
-](/solutions/pay-your-way)
-
-[
-
-Branch App & Card
-
-](/solutions/branch-app-and-card)
-
-[
-
-Branch Direct
-
-](/solutions/branch-direct)
-
-[
-
-Embedded Finance
-
-](/solutions/branch-embedded-finance)
-
-[
-
-Custom Branded Solutions
-
-](/solutions/custom-branded-solutions)
-
-industries
-
-[
-
-Healthcare
-
-](/industry/healthcare)
-
-[
-
-Hospitality
-
-](/industry/hospitality)
-
-[
-
-Gig Platforms & Marketplaces
-
-](/industry/gig-platforms-marketplaces)
-
-[
-
-Logistics & Transportation
-
-](/industry/logistics-transportation)
-
-[
-
-Business Services
-
-](/industry/business-services)
-
-[
-
-Construction & Energy
-
-](/industry/construction)
-
-[
-
-Agriculture
-
-](/industry/agriculture)
-
-use cases
-
-[
-
-Cashless Tips & Mileage
-
-](/use-cases/cashless-tips-mileage)
-
-[
-
-Earned Wage Access
-
-](/use-cases/earned-wage-access)
-
-[
-
-Financial Wellness
-
-](/use-cases/financial-wellness-tools)
-
-[
-
-Paycard & Direct Deposit
-
-](/use-cases/paycard-direct-deposit)
-
-[
-
-1099 Independent Contractor Payouts
-
-](/use-cases/1099-independent-contractor-payouts)
-
-[
-
-W-2 Employee Payments
-
-](/use-cases/w-2-employee-payments)
-
-resources
-
-[
-
-All Resources
-
-](/resources)
-
-[
-
-Blog
-
-](/blog)
-
-[
-
-Books & Guides
-
-](/resources?type=Books+%26+Guides)
-
-[
-
-Reports & Data
-
-](/resources?type=Reports)
-
-[
-
-Case Studies
-
-](/case-studies)
-
-company
-
-[
-
-About Branch
-
-](/about)
-
-[
-
-Contact
-
-](/contact)
-
-[
-
-Jobs
-
-](https://job-boards.greenhouse.io/branch)
-
-[
-
-News
-
-](/news)
-
-[Integrations](/integrations)
-
-[Start Today](/demo)[How It Works](/solutions/pay-your-way)
-
-# Fueling the Future of Workforce Payments
-
-Branch delivers faster, more flexible options for businesses to pay their workers, empowering people with easy access to earnings and tools to build financial freedom.
-
-[Start Today](/demo)[How It Works](/solutions/pay-your-way)
-
-Trusted by
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## Branch Works for You
-
-Explore all the ways our award-winning, end-to-end platform helps you and your workers thrive.
-
-## Simple Setup, Instant Access
-
-Whether you’re looking to launch a turnkey or customized payments experience, we’ve got a solution that meets your needs.
-
-[Get a Demo](/demo)
-
-
-
-Easy to Launch
-
-Easy to set up, no matter your technical skills or timeline. Start sending money to your team on day one—no large deposits or pre-funding required.
-
-
-
-Seamless Integrations
-
-We can work with all kinds of HCM, payroll, tax, and time & attendance systems. [Check out integrations](/integrations)
-
-
-
-Customizable Options
-
-From ready-to-use payout solutions to custom branded payment experiences, choose from a variety of options to suit your needs.
-
-
-
-Available for Free
-
-Branch is available at no cost to companies and offers free options for workers. Earners that sign up with Branch can receive a free bank account, fast access to earnings, and personal finance tools to help set long-term goals.
-
-
-
-## Improve Hiring & Productivity
-
-Faster payouts can attract top talent and keep workers coming back for their next shift.
-
-### 83%
-
-of employees believe they should be able to access their pay each day [\[source\]](https://www.forbes.com/sites/edwardsegal/2021/09/13/most-workers-want-to-be-paid-automatically-every-day-according-to-new-poll/?sh=11d12037293f)
-
-### 1 in 3
-
-individuals claim financial stress has negatively impacted workplace productivity [\[source\]](https://www.forbes.com/sites/edwardsegal/2021/09/13/most-workers-want-to-be-paid-automatically-every-day-according-to-new-poll/?sh=11d12037293f)
-
-### 2.5x
-
-increase in applicants when on-demand pay was added to the job description \[Branch customer survey\]
-
-### 86%
-
-felt more incentivized to work when on-demand pay was offered \[Branch customer survey\]
-
-
-
-## Industries That Trust Branch
-
-Branch simplifies payments and helps businesses thrive across a spectrum of industries.
-
-
-
-
-
-[
-
-Healthcare
-
-](/industry/healthcare)
-
-[
-
-Hospitality
-
-](/industry/hospitality)[
-
-Logistics & Transportation
-
-](/industry/logistics-transportation)
-
-[
-
-Business Services
-
-](/industry/business-services)[
-
-Gig Platforms & Marketplaces
-
-](/industry/gig-platforms-marketplaces)
-
-## What Our Customers Are Saying
-
-From time and money saved to reduced staff turnover, Branch has made an impact for businesses of all sizes.
-
-Manna
-
-“The number one question that our applicants ask—especially younger applicants—is whether or not we have earned wage access. You will knock yourself out of the game if you’re not offering that to your employees.”
-
-Mary Lazzaroni
-
-,
-
-VP of Human Resources
-
-
-
-Read their story
-
-[](/case-studies/manna)
-
-Hop City Craft Beer & Wine
-
-“It speeds things up a lot. On a Friday night, the manager is responsible for paying out the whole staff at the end of the night… that is time-consuming, just the physical manual labor. I’d say it saves between 1-2 hours of management time each day. Now the process takes 10 minutes, tops.”
-
-CJ Dimino
-
-,
-
-Director of Restaurant Operations
-
-
-
-Read their story
-
-[](/case-studies/hop-city)
-
-StaffHealth
-
-“Same-day pay has been the #1 tool in reducing the level of no-call, no-shows we experience”
-
-Anthony Miller
-
-,
-
-Director of Operations
-
-
-
-Read their story
-
-[](/case-studies/staffhealth)
-
-Servicon
-
-"In the past, many employees had to use payday lenders and similar entities for loans with interest rates that are sky high. Branch gives them the best option for getting cash at zero cost to them."
-
-Liliana Monter, a Payroll Manager
-
-,
-
-
-
-Read their story
-
-[](/case-studies/servicon)
-
-Three15
-
-“I had an initial phone call and I think we were live a couple hours later. We ended up getting everyone paid with Branch that day.”
-
-Mandy Moseley
-
-,
-
-Owner, Three15 Studios
-
-
-
-Read their story
-
-[](/case-studies/three15)
-
-## Latest Insights
-
-Explore the future of work and payments
-
-[More Insights](/blog)
-
-[
-
-
-
-Hiring on Demand: How Staffing Firms Can Win with Event-Driven Demand
-
-Read more
-
-
-
-
-
-
-
-](/blog/hiring-on-demand-how-staffing-firms-can-win)
-
-[
-
-
-
-From Cash Tips to Digital Wallets: The Evolution of Tipping and What It Means for Operators
-
-Read more
-
-
-
-
-
-
-
-](/blog/from-cash-tips-to-digital-wallets-the-evolution-of-tipping)
-
-[
-
-
-
-Defining Success in the Trades: How to Improve Subcontractor Satisfaction in Construction
-
-Read more
-
-
-
-
-
-
-
-](/blog/how-to-improve-subcontractor-satisfaction-in-construction)
-
-## Unlock a Happier, More Productive Workforce
-
-[Start using Branch today](/demo)
-
-
-
-[](/)
-
-Branch delivers faster, more flexible options for people to get paid.
-
-[
-
-](https://www.facebook.com/branch/)[
-
-](https://www.instagram.com/branch.app/)[
-
-](https://x.com/branch)[
-
-](https://www.linkedin.com/company/branch-app/)
-
-Solutions
-
-- [Pay Your Way](/solutions/pay-your-way)
-- [Branch App & Card](/solutions/branch-app-and-card)
-- [Branch Direct](/solutions/branch-direct)
-- [Embedded Finance](/solutions/branch-embedded-finance)
-- [Custom Branded Solutions](/solutions/custom-branded-solutions)
-
-Industries
-
-- [Healthcare](/industry/healthcare)
-- [Hospitality](/industry/hospitality)
-- [Gig Platforms & Marketplaces](/industry/gig-platforms-marketplaces)
-- [Logistics & Transportation](/industry/logistics-transportation)
-- [Business Services](/industry/business-services)
-- [Construction](/industry/construction)
-
-Use Cases
-
-- [Cashless Tips & Mileage](/use-cases/cashless-tips-mileage)
-- [Earned Wage Access](/use-cases/earned-wage-access)
-- [Financial Wellness](/use-cases/financial-wellness-tools)
-- [Paycard & Direct Deposit](/use-cases/paycard-direct-deposit)
-- [1099 Independent Contractor Payouts](/use-cases/1099-independent-contractor-payouts)
-- [W-2 Employee Payments](/use-cases/w-2-employee-payments)
-
-Resources
-
-- [All Resources](/resources)
-- [Blog](/blog)
-- [Books & Guides](/resources?type=Books+%26+Guides)
-- [Reports & Data](/resources?type=Reports)
-- [Case Studies](/case-studies)
-
-Company
-
-- [Integrations](/integrations)
-- [About Branch](/about)
-- [Contact](/contact)
-- [Jobs](https://job-boards.greenhouse.io/branch)
-- [News](/news)
-
-Help
-
-- [Terms](/legal/start)
-- [App Support](https://support.branchapp.com/hc/en-us)
-- [Admin Login](https://payadmin.branchapp.com/login)
-- [Security Portal](https://security.branchapp.com/)
-- [Your Privacy Options](#)
-
-© Branch
-
-2026
-
- - All Rights Reserved
-
-Branch is not a bank. Banking services are provided by Evolve Bank & Trust, Member FDIC or Lead Bank, Member FDIC (“Sponsor Banks”), as listed on the back of a user's Branch Card. FDIC insurance only applies for eligible accounts should the Sponsor Bank holding the user's funds fail. The Branch Mastercard Debit Card is issued by the Sponsor Bank pursuant to a license from Mastercard and may be used everywhere Mastercard debit cards are accepted.
-
-
-
-### Your Privacy Options
-
-We use cookies to provide you with the best possible experience. They also allow us to analyze user behavior in order to constantly improve the website for you.
-
-[See our Cookie Policy](/cookie-policy)
-
-Reject all
-
-Cookie choices
-
-Accept All
-
-Functionality
-
-Analytics Storage
-
-Ad Storage
-
-Ad User Data
-
-Ad Personalisation
-
-Personalization Storage
-
-Security Storage
-
-Thank you! Your submission has been received!
-
-Oops! Something went wrong while submitting the form.
-
-Accept selection
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.captivateiq.com/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
-Sales Commission Management Software | CaptivateIQ
-
-Javascript must be enabled for the correct page display
-
-Captivate26 is coming to Austin. Join revenue, finance, and comp leaders for real, hands-on conversations. [Register today](/captivate-26)
-
-[](#)
-
-[.svg)](/)
-
-[Why CaptivateIQ](/why-captivateiq)
-
-Products
-
-[Back to Menu](#)[Product](#)
-
-Product
-
-[
-
-CaptivateIQ Incentives
-
-Automate commissions and deliver a better Return on Incentives.
-
-](/incentives)[
-
-CaptivateIQ Planning
-
-Simplify sales planning and maximize territory effectiveness.
-
-](/planning)[
-
-CaptivateIQ Catalyst
-
-Advanced modeling layer for planning and incentives with predictive ML.
-
-](/catalyst)
-
-Platform Capabilities
-
-[
-
-Data Integrations
-
-](/all-integrations)[
-
-SmartGrid™: ELT & Calculation Engine
-
-](/smartgrid)[
-
-Assist: AI-Powered Intelligence
-
-](/assist)[
-
-Enterprise Workflow Automation
-
-](/enterprise-workflow-automation)
-
-Use Cases
-
-- [
-
- Incentive Compensation Management
-
- ](/incentives)
-- [
-
- Capacity Planning
-
- ](/sales-capacity-planning)
-- [
-
- Quota Setting
-
- ](/quota-setting)
-- [
-
- Territory Management
-
- ](/territory-planning)
-- [
-
- Predictive Modeling
-
-
- ](/catalyst)
-- [
-
- Bonuses & MBO Management
-
-
- ](/bonuses)
-
-
-
-See for yourself with a product tour
-
-[SPM](https://captivateiq.navattic.com/73c405je)
-
-Solutions
-
-[Back to Menu](#)
-
-for your organization
-
-[
-
-Enterprise
-
-](/enterprise)[
-
-Mid-Market
-
-](/midmarket)[Partners](/partners)[Security & Privacy](/trust)[SOX Compliance](/sox)
-
-for your role
-
-[
-
-Compensation Professionals
-
-](/compensation-manager)[
-
-Finance & Accounting
-
-](/finance-accounting)[
-
-Sales & Revenue Operations
-
-](/revenue-operations)[
-
-Sales Management
-
-](/sales-management)
-
-for your industry
-
-- [
-
- Financial Services
-
- ](/financial-services)
-- [
-
- Manufacturing
-
- ](/manufacturing)
-- [
-
- Media & Entertainment
-
- ](/media-entertainment)
-- [
-
- Medical Devices
-
- ](/medical-device)
-- [
-
- Retail & Wholesale
-
- ](/retail-wholesale)
-- [
-
- Technology
-
- ](/technology)
-
-Resources
-
-[Back to Menu](#)
-
-EXPLORE COMPANY
-
-[
-
-About CaptivateIQ
-
-The modern sales commission solution to 10x revenue performance.
-
-](/about-us)
-
-- [Careers](/careers)
-- [Contact Us](/contact)
-
-LearnING RESOURCES
-
-- [
-
- Customers
-
- Explore how our customers are running commissions with ease and confidence.
-
- ](/customers)
-- [
-
- Resources
-
- Discover best practices, research reports, and expert guides to supercharge your success.
-
- ](/resources)
-- [
-
- Events
-
- Register for upcoming events featuring captivating guest speakers, or catch up on-demand.
-
- ](/events)
-- [
-
- Blog
-
- Unlock the latest insights and best practices on ICM trends and beyond.
-
- ](/blog)
-- [
-
- ROI Calculator
-
- Calculate your potential ROI with CaptivateIQ.
-
- ](/roi-calculator)
-
-[
-
-Explore our new thought leadership hub for all things incentive compensation management
-
-See what's new
-
-](https://multiplier.captivateiq.com/)
-
-[Pricing](/pricing)
-
-- [Login](https://app.captivateiq.com/login)
-- [Book a Meeting](https://www.captivateiq.com/request-demo)
-
-[
-
-Opener
-
-](#)
-
-# Planning and incentives in sync.
-
-Finally.
-
-Bring capacity, quotas, territories, and incentives together in a single AI-infused workspace built for agility, alignment, and scale.
-
-[Book a Meeting](#)[Tour the Product](https://www.captivateiq.com/product-tour-general-overview)
-
-[
-
-
-
-](#)
-
-
-
-
-
-Trusted by 800+ companies to chart the path to resilient revenue
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Planning & Incentives
-
-
-
-Built to
-adapt.
-
-## One AI-infused platform
-from planning to payout.
-
-From setting objectives to calculating payouts, everything you need to plan, execute, monitor, and adapt tightly integrated sales and incentive compensation strategy. All without relying on services or IT.
-
-SmartGrid ELT
-
-Work off a single source of truth for incentives and planning. Ingest data from any source and transform it in real-time with the SmartGrid ELT modeling engine. Ensuring every model and calculation is built off a clean, up to date dataset.
-
-[Explore this Capability](/smartgrid)
-
-Incentive Compensation Management
-
-Automate commission calculations with precision and transparency. Build any commission plan, give payees real-time visibility into earnings and ensure your incentives are driving desired outcomes.
-
-[Explore this Capability](/incentives)
-
-Sales Capacity and Quota Planning
-
-Balance workloads and ramp times while ensuring quotas are both achievable and aligned with business goals. Compare scenarios to get the right people in seat to hit targets.
-
-[Explore this Capability](/quota-setting)
-
-Territory Management
-
-Build and manage territories that drive results. Automatically assign accounts, optimize opportunities across reps, and adapt boundaries as your business evolves—all with clear alignment across sales and operations.
-
-[Explore this Capability](/territory-planning)
-
-Reporting & Analytics
-
-Turn planning and incentives data into actionable insights. Track performance trends, identify top performers, and understand what drives results with advanced reporting and real-time dashboards that inform strategic decisions.
-
-[Explore this Capability](/product/captivate)
-
-Predictive Modeling
-
-Forecast outcomes before they happen. Use ML-powered models to score accounts, predict quota attainment and identify payout anomalies based on historical performance and trends.
-
-[Explore this Capability](/catalyst)
-
-Assist AI
-
-Build faster, with confidence. Quickly troubleshoot formulas, search documentation, optimize plans and improve payee visibility with natural language queries and intelligent suggestions.
-
-[Explore this Capability](/assist)
-
-## Revenue resilience,
-delivered.
-
-You need strategy that grows stronger when things change. That's revenue resilience, and it's built into CaptivateIQ.
-
-[Explore our ROI Calculator](/roi-calculator)
-
-
-
-10%
-
-increase in seller attainment
-
-6x
-
-faster plan creation
-
-47%
-
-faster commissions process
-
-9.5%
-
-increase in seller attainment
-
-## CaptivateIQ
-is built for agility.
-
-Legacy tools weren’t designed for speed or adaptability. We built CaptivateIQ to make incentive compensation management and planning painless and wildly effective.
-
-[Book a Meeting](#)
-
-
-
-Connected workspace
-
-## One source of truth
from capacity planning to payouts
-
-- Clean, up-to-date dataset powered by SmartGrid
-- Connected modeling across planning and incentives
-- Single source-of-truth across finance, sales ops and compensation
-- Real-time commission visibility for payees and leadership
-
-
-
-Unbeatable flexibility
-
-## Plan for anything, pivot anytime
-
-- Logic-based workbooks handle compensation plan complexity with ease
-- No-code calculation engine to build & adapt without services
-- Guided plan-building and scenario modeling with AI Assist
-
-
-
-Intelligent optimization
-
-## Make better decisions, faster
-
-- Real-time scenario modeling for planning & incentives
-- End-to-end reporting out of the box
-- Custom predictive ML models including forecasting and anomaly detection
-
-## Helping operations teams
-run smarter and move faster.
-
-
-
-
-
-
-
-
-
-
-
-Michael D.
-
-Director of Revenue Operations
-
-“Through its flexibility, transparency and automation, CaptivateIQ has become an essential partner in scaling revenue operations for our fast-growing sales organization.”
-
-60x
-
-faster at calculating monthly commissions
-
-[Read their story](/customers/gong)
-
-
-
-Brian D.
-
-Director of Sales Finance
-
-"The downstream effects were significant. We were spending so much time on administrative tasks that we couldn’t focus on the real business problems that we wanted to be solving."
-
-60
-
-hours saved per month
-
-[Read their story](/customers/tipalti)
-
-
-
-Alex W.
-
-Senior Variable Compensation Analyst
-
-“The additional time \[from CaptivateIQ\] frees up space for analysis … it means I can ensure that our commission plans are really designed to be aligned with our company goals.”
-
-2 days
-
-to roll out new plans
-
-[Read their story](#)
-
-## Complexity,
-meet simplicity.
-
-No more crashing Excel files or unmet promises from professional services. Tackle even the most complex sales and compensation plans with speed and confidence.
-
-[Explore Enterprise](/enterprise)[Tour the Product](https://www.captivateiq.com/product-tour-general-overview)
-
-
-
-### Scale with SmartGrid
-
-Having firsthand experience with the pain of commissions, our founders built a modern modeling experience. With our SmartGrid™ ELT & calculation engine, you can model plans and calculate commissions at scale.
-
-
-
-### Get up and running - fast
-
-Quickly model and test incentives, capacity, territories and quota in real-time without breaking the bank. Launch in as little as two weeks to three months.
-
-
-
-### Stay in the driver’s seat
-
-CaptivateIQ’s no-code platform pairs flexibility with ease of use for all your incentive and planning needs. Create reports, test plan changes, and manage incentive compensation with just a few clicks — no technical expertise necessary.
-
-
-
-### Comprehensive security and compliance
-
-Protecting your sensitive data is our top priority. Our compliance program meets industry-leading information security standards, undergoing annual independent audits for SOC 1 and SOC 2 compliance.
-
-
-
-
-
-
-
-
-
-## We built it because we lived it. Now we’re sharing what we know.
-
-CaptivateIQ started when a few ops leaders hit their limit with broken corp spreadsheets and legacy tools. Now, we help hundreds of companies build better plans, pay accurate commissions, and grow with confidence. Explore insights from the front lines of compensation and planning.
-
-[Learn More](/why-captivateiq)
-
-## Frequently asked questions
-
-[
-
-How does CaptivateIQ automate commissions?
-
-](#)
-
-CaptivateIQ automates commissions by pulling actual sales data from connected CRM systems, applying custom compensation rules to each deal, and generating real-time payout statements. Commission plans are defined using a visual modeling engine called SmartGrid and stay continuously in sync with closed revenue as data updates.
-
-Plans can include:
-
-- Tiers and accelerators
-
-- Bonuses and SPIFs
-
-- Draw structures
-
-- Eligibility rules
-
-
-SmartGrid handles these structures at scale, so teams can update logic, test scenarios, and maintain accuracy as plans evolve.
-
-[
-
-Why do 800+ companies use CaptivateIQ for Sales Planning & Incentive Management?
-
-](#)
-
-Over 800 companies use CaptivateIQ to manage sales planning and incentive compensation because the platform supports complex plans with high accuracy, flexibility, and transparency. CaptivateIQ replaces manual spreadsheets and rigid legacy tools with automated calculations, real-time visibility, and scalable governance across sales organizations.
-
-[
-
-What’s the advantage of using CaptivateIQ?
-
-](#)
-
-The primary advantage of using CaptivateIQ is the ability to manage complex compensation and planning workflows without heavy IT involvement. The platform combines flexibility, automation, and auditability to support accurate payouts and confident decision-making at scale.
-
-[
-
-What makes CaptivateIQ's incentive management unique?
-
-](#)
-
-CaptivateIQ’s incentive management is unique because it allows compensation logic to be modeled visually while maintaining full traceability from source data to payout. This approach enables rapid plan changes without sacrificing accuracy or control.
-
-[
-
-How does CaptivateIQ ensure data security?
-
-](#)
-
-CaptivateIQ ensures data security through enterprise-grade controls including SOC 2 compliance, encryption at rest and in transit, and role-based access permissions. These safeguards protect sensitive sales, compensation, and employee data across the platform.
-
-[
-
-How is CaptivateIQ's pricing structured?
-
-](#)
-
-CaptivateIQ pricing is structured based on the number of payees, compensation complexity, and required integrations. Pricing is typically tailored to the scope and requirements of each organization’s sales compensation programs.
-
-[
-
-What are the benefits of real-time reports?
-
-](#)
-
-Real-time reports provide immediate visibility into performance, attainment, and expected payouts as sales activity occurs. This visibility helps organizations identify issues earlier and make faster, more informed planning and compensation decisions.
-
-[
-
-Does CaptivateIQ integrate with CRM and payroll systems?
-
-](#)
-
-Yes. CaptivateIQ integrates with Salesforce, HubSpot, NetSuite, Workday, and other source systems to automate data flow and reduce manual work. APIs and data import options allow additional customization. More information on integrations can be found [here](/all-integrations).
-
-[
-
-How does CaptivateIQ ensure data security?
-
-](#)
-
-CaptivateIQ ensures data security through enterprise-grade controls including SOC 2 compliance, encryption at rest and in transit, and role-based access permissions. Customer data is isolated and protected to meet enterprise security requirements.
-
-[
-
-How is CaptivateIQ priced?
-
-](#)
-
-CaptivateIQ pricing is based on company size, compensation complexity, and the modules in use, such as commissions and sales planning. Pricing is typically customized to align with organizational requirements.
-
-[
-
-Why do companies choose CaptivateIQ over other sales compensation tools?
-
-](#)
-
-Companies choose CaptivateIQ for its flexibility, accuracy, and ability to support complex compensation plans without heavy IT dependency. The platform enables rapid plan changes while maintaining transparency and control at scale. Learn how top enterprise businesses have decreased the time they spend on commissions by 75% [here](/customers).
-
-## Join the 800 companies building resilient revenue
-with CaptivateIQ
-
-[Book a Meeting](#)
-
-### Let’s customize your demo, takes 30 seconds.
-
-See how top teams automate commissions.
-
-
-
-[](#)
-
-
-
-Take a quick tour of CaptivateIQ.
-
-Experience the #1 software for Sales and Incentive Planning through a quick self-guided tour.
-
-[Tour the product](https://capture.navattic.com/split/cmhaypgjc01r7la04wh9re1ci)
-
-Sign up for our newsletter
-to get the latest ICM insights and best practices
-
-
-
-By clicking “Sign Up”, you acknowledge CaptivateIQ’s [Privacy Policy](/privacy-policy).
-
-[Product](#)
-
-- [Assist](/assist)
-- [Automate Commissions](/product/automate)
-- [Bonuses & MBOs](/bonuses)
-- [Captivate with Insights](/product/captivate)
-- [Enterprise Workflow Automation](/enterprise-workflow-automation)
-- [Incentives](/incentives)
-- [Integrations](/all-integrations)
-- [Motivate Seller Performance](/product/motivate)
-- [Planning](/planning)
-- [Platform Overview](/platform)
-- [Pricing](/pricing)
-- [Product Tour: Incentives](https://captivateiq.navattic.com/695l0e0h)
-- [Product Tour: Planning](https://captivateiq.navattic.com/9t10i64)
-
-- [SmartGrid™](/smartgrid)
-- [Guided Plan Builder](/guided-plan-builder)
-- [Why CaptivateIQ?](/why-captivateiq)
-
-[Solutions](#)
-
-- [Compensation Manager](/compensation-manager)
-- [Enterprise](/enterprise)
-- [Finance & Accounting](/finance-accounting)
-- [Financial Services](/financial-services)
-- [Mid-Market](/midmarket)
-- [Manufacturing](/manufacturing)
-- [Media & Entertainmet](/media-entertainment)
-- [Medical Device](/medical-device)
-- [Operations](/revenue-operations)
-- [Partners](/partners)
-- [Retail & Wholesale](/retail-wholesale)
-- [Sales Leader](/sales-management)
-- [Technology](/technology)
-
-[Legal, Privacy & Security](#)
-
-- [Legal Overview](/legal-overview)
-- [Security & Privacy](/security-policy)
-- [SOX Compliance](/sox)
-
-[Resources](#)
-
-- [Benchmarking & Market Trends](/resources)
-- [Blog](/blog)
-- [Customers](/customers)
-- [Events](/events)
-- [The Multiplier](https://multiplier.captivateiq.com/)
-
-[Company](#)
-
-- [About CaptivateIQ](/about-us)
-- [Careers](/careers)
-- [Contact](/contact)
-
-[Compare](#)
-
-- [Sales Compensation Software Reviews](https://www.captivateiq.com/explainer/sales-compensation-software-reviews)
-- [vs. CallidusCloud](/comparison/callidus)
-- [vs. Everstage](/comparison/everstage)
-- [vs. Performio](/comparison/performio)
-- [vs. QuotaPath](/comparison/quotapath)
-- [vs. Spiff](/comparison/spiff)
-- [vs. Varicent](/comparison/varicent)
-- [vs. Xactly](/comparison/xactly)
-
-[Explainers](#)
-
-- [ASC 606](https://www.captivateiq.com/explainer/asc-606-revenue-recognition)
-- [Commission Automation Software](https://www.captivateiq.com/explainer/commission-automation-software)
-- [Commission Tracking Software](https://www.captivateiq.com/explainer/commission-tracker)
-- [Compensation Management Software](https://www.captivateiq.com/explainer/compensation-management)
-- [Incentive Compensation Management Software](https://www.captivateiq.com/explainer/incentive-compensation-management)
-- [Sales Commission Calculator](https://www.captivateiq.com/explainer/sales-commission-calculator)
-- [Sales Commission Reporting Software](https://www.captivateiq.com/explainer/reporting)
-- [Sales Commission Software](http://www.captivateiq.com/explainer/sales-commission-software)
-- [Sales Management Software](https://www.captivateiq.com/explainer/sales-software)
-- [Sales Performance Management Software](https://www.captivateiq.com/explainer/sales-performance-management)
-- [Sales Planning Software](https://www.captivateiq.com/explainer/sales-planning-software)
-- [Territory Management Software](https://www.captivateiq.com/explainer/territory-management-software)
-
-© CaptivateIQ, Inc. All rights reserved. Various trademarks held by their respective owners. Featured users may have been compensated; opinions are their own. Customer experiences may vary.
-
-- [Privacy Policy](/privacy-policy)
-- [CA Privacy Notice](https://www.captivateiq.com/privacy-policy#california)
--  Your Privacy Choices
-
-- [Sitemap](/sitemap)
-
-Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read more about Forrester’s objectivity [here](https://www.forrester.com/about-us/objectivity/).
-
-Gartner® and Peer Insights™ are trademarks of Gartner, Inc. and/or its affiliates. All rights reserved. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences, and should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.caju.com.br/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
-Caju • Facilite o seu dia a dia e transforme a experiência dos seus colaboradores
-
-[](/)
-
-Plataforma
-
-O essencial
-
-[
-
-Benefícios
-
-](/plataforma/beneficios)[
-
-Bem-estar e saúde
-
-](/plataforma/saude-e-bem-estar)[
-
-Premiação
-
-](/plataforma/premiacoes)[
-
-Despesas
-
-](/plataforma/despesas)[
-
-Pessoas
-
-](/plataforma/pessoas)
-
-Especiais
-
-[
-
-Promoção Benefícios + Wellhub
-
-](https://produtos.caju.com.br/caju-wellhub-promo%C3%A7%C3%A3o?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=home&utm_content=menu)[](https://produtos.caju.com.br/seguranca-juridica-2?utm_source=Site&utm_medium=referral&utm_campaign=seguranca_juridica&utm_content=menu_site)
-
-Soluções
-
-Por segmentos
-
-[
-
-Indústria
-
-](/solucoes/industria)[
-
-Serviços
-
-](/solucoes/servicos)[
-
-Tecnologia
-
-](/solucoes/tecnologia)[
-
-Varejo
-
-](/solucoes/varejo)
-
-Por tamanho
-
-[
-
-Pequenas empresas
-
-](/solucoes/pequenas-empresas)[
-
-Médias empresas
-
-](/solucoes/medias-empresas)[
-
-Grandes empresas
-
-](/solucoes/grandes-empresas)
-
-[
-
-Planos
-
-](/planos)
-
-A Caju
-
-Sobre nós
-
-[
-
-A Caju
-
-](/a-caju/a-caju)[
-
-Blog
-
-](https://blog.caju.com.br/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA.)[
-
-Materiais ricos
-
-](https://produtos.caju.com.br/materiais-gratuitos)[
-
-Cajuína
-
-](https://cajuina.org/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA)[
-
-Revenda Caju
-
-](/revenda-caju)[
-
-Cultura e Carreira
-
-](/cultura-e-carreira)
-
-Contato
-
-[
-
-Central de ajuda
-
-](https://ajuda.caju.com.br/s/)[
-
-Fale conosco
-
-](/a-caju/fale-conosco)
-
-Segurança
-
-[
-
-Segurança e certificados
-
-](/a-caju/seguranca-e-certificados)
-
-[
-
-](#)[
-
-Login
-
-](https://auth.caju.com.br/realms/caju/protocol/openid-connect/auth?client_id=sponsor-app&redirect_uri=https%3A%2F%2Fempresa.caju.com.br%2Flogin%2F%23%3F&state=f5f2b387-3a63-4e60-80ea-2cb90a7d33ca&response_mode=fragment&response_type=code&scope=openid&nonce=1c44eb22-cd7d-4dbd-8ece-cc58bcbc0d65&code_challenge=5Lb0J6kMr5CpgFcKu3o5vMip8zSo6ivRbftoGQvvmeo&code_challenge_method=S256)
-
-[Demonstração](https://produtos.caju.com.br/demonstracao-caju-multibeneficios?utm_source=home_site&utm_medium=referral&utm_campaign=demonstracao_caju_multibeneficios&utm_content=header_site&utm_term=botao_header)[Quero Caju](https://quero.caju.com.br/)
-
-[**Mudanças no PAT:** veja o que o novo decreto altera e como manter sua empresa regularizada. **Saiba mais!**](https://produtos.caju.com.br/seguranca-juridica-2?utm_source=Site&utm_medium=referral&utm_campaign=seguranca_juridica&utm_content=faixa_site)
-
-# Facilite o seu dia a dia e transforme a experiência dos seus colaboradores
-
-Da admissão à retenção, centralize benefícios, despesas e gestão de pessoas em uma única plataforma e com taxa zero\*
-
-[
-
-Quero saber mais
-
-](#)
-
-Em breve você receberá as novidade da Caju!
-
-Oops! Something went wrong while submitting the form.
-
-[](https://produtos.caju.com.br/caju-wellhub-promo%C3%A7%C3%A3o?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=home&utm_content=banner)
-
-+50 mil empresas confiam na Caju
-
-
-
-
-
-
-
-## Centralize benefícios, despesas e pessoas com a Caju
-
-Ganhe agilidade no RH e foco no crescimento da sua empresa.
-
-
-
-Benefícios
-
-Gestão simples de benefícios com segurança jurídica garantida.
-
-Controle total do saldo de benefícios CLT, PAT e flexíveis.
-
-[Contrate agora](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-
-
-Despesas
-
-Despesas integradas ao cartão e app Caju, sem complicação.
-
-Unifique reembolsos, adiantamentos e despesas em uma única plataforma.
-
-[Contrate agora](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-
-
-Pessoas
-
-Gerencie toda a jornada do colaborador em um só lugar.
-
-Simplifique processos e traga mais eficiência para o seu RH.
-
-[Contrate agora](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-## Conheça o plano Essencial
-
-A solução ideal para pequenas e médias empresas: multibenefícios, gestão de despesas e de pessoas em uma única plataforma — tudo integrado, simples de usar e com taxa zero\*.
-
-[Contrate agora](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-.gif)
-
-
-
-## Da pequena empresa à grande corporação, a Caju deixa a rotina mais leve e eficiente
-
-[Fale com um especialista](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-Pequenas
-
-Tudo que você precisa para organizar seu RH de forma ágil, prática e sem pagar taxa
-
-[Saiba mais >](/solucoes/pequenas-empresas)
-
-Médias
-
-Uma plataforma completa para modernizar o RH e gerenciar toda a jornada do seu colaborador
-
-[Saiba mais >](/solucoes/medias-empresas)
-
-Grandes
-
-Soluções multibenefícios modulares, flexíveis e integradas, do jeito que sua empresa precisa
-
-[Saiba mais >](/solucoes/grandes-empresas)
-
-
-
-Pequenas
-
-[Tudo que você precisa para organizar seu RH de forma ágil, prática e sem pagar taxa](#)
-
-[Saiba mais](#)
-
-
-
-Médias
-
-[Uma plataforma completa para modernizar o RH e gerenciar toda a jornada do seu colaborador](#)
-
-[Saiba mais](#)
-
-
-
-Grandes
-
-[Soluções multibenefícios modulares, flexíveis e integradas, do jeito que sua empresa precisa](#)
-
-[Saiba mais](#)
-
-# Quem escolhe Caju vê resultado!
-
-Menos tempo perdido com burocracia
-
-Mais facilidade para atrair e manter talentos
-
-Colaboradores mais engajados
-
-Quem usa, ama
-
-Para organizações de todos os portes
-
-
-
-30%
-
-menos tempo em tarefas operacionais
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-
-
-80%
-
-dos clientes dizem que a Caju melhora a atração e retenção de talentos
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-
-
-71%
-
-das empresas notam mais engajamento dos colaboradores
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-
-
-+1 milhão
-
-de colaboradores com acesso a benefícios que valorizam de verdade
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-
-
-+50 mil
-
-empresas simplificam a rotina com Caju
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-Menos tempo perdido com burocracia
-
-30%
-
-menos tempo em tarefas operacionais
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-Mais facilidade para atrair e manter talentos
-
-65%
-
-dos clientes dizem que a Caju melhora a atração e retenção de talentos
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-Colaboradores mais engajados
-
-71%
-
-das empresas notam mais engajamento dos colaboradores
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-Quem usa ama
-
-\+ 1 milhão
-
-de colaboradores com acesso a benefícios que valorizam de verdade
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-Para organizações de todos os portes
-
-\+ 50 mil
-
-empresas simplificam a rotina com Caju
-
-[Contrate agora](https://quero.caju.com.br/?_gl=1*150iziw*_ga*MTAwNjgwMDAyMi4xNzU0MzE1MTU2*_ga_3RPJSREWE0*czE3NjAxMjQ5OTYkbzI2JGcxJHQxNzYwMTI3NTczJGozNSRsMCRoMA..)
-
-## Conheça histórias de quem está colhendo os frutos
-
-[
-
-](#)[
-
-](#)
-
-[
-
-](#)
-
-
-
-Joziane Matheus, Coordenadora de RH
-
-“Quando chegou o cartão da Caju com todas essas funções foi uma novidade fantástica, ficamos apaixonados e desde então a gente não tem o que reclamar”
-
-[Ver case completo](#)
-
-[
-
-](#)
-
-
-
-Priscila Melo, Analista de RH
-
-“A plataforma da Caju é muito intuitiva e a gente não teve trabalho nenhum, só baixou a planilha, passou os dados e pronto”
-
-[Ver case completo](#)
-
-[
-
-](#)
-
-
-
-Elizabeth Jeha, Coordenadora de soluçes
-
-“Com certeza eu recomendo a Caju, como colaboradora e como coordenadora de RH. É realmente um benefício que vem para trazer muitas melhorias para a empresa.”
-
-[Ver case completo](#)
-
-## Soluções que cuidam de quem constrói a sua empresa
-
-Cuidado completo, do trajeto à consulta. Caju facilita o acesso a bem-estar, saúde e transporte para o seu time.
-
-[Fale com um especialista](#)
-
-.gif)
-
-Saúde e bem-estar
-
-Caju conecta sua empresa a serviços de saúde e bem-estar, com gestão simples e uma ampla rede de parceiros.
-
-
-
-Mobilidade
-
-Gestão automatizada de vale-transporte e
preço fixo por colaborador.
-
-[Fale com um especialista](https://quero.caju.com.br/?utm_source=site&utm_medium=referral&utm_campaign=site&utm_term=botao_contrate&utm_content=despesas)
-
-## Conheça a Caju na prática!
-
-Assista à nossa demonstração e veja como simplificar a gestão de benefícios e despesas de forma eficiente
-
-[Demonstração](https://produtos.caju.com.br/demonstracao-caju-multibeneficios?utm_source=home_site&utm_medium=referral&utm_campaign=demonstracao_caju_multibeneficios&utm_content=video_bottom&utm_term=cta_video)
-
-[Demonstração](https://produtos.caju.com.br/demonstracao-caju-multibeneficios?utm_source=home_site&utm_medium=referral&utm_campaign=demonstracao_caju_multibeneficios&utm_content=video_bottom&utm_term=cta_video)
-
-## Conheça a Caju na prática!
-
-Assista à nossa demonstração e veja como simplificar a gestão de benefícios e despesas de forma eficiente
-
-[Demonstração](https://produtos.caju.com.br/demonstracao-caju-multibeneficios?utm_source=home_site&utm_medium=referral&utm_campaign=demonstracao_caju_multibeneficios&utm_content=video_bottom&utm_term=cta_video)
-
-[Demonstração](https://produtos.caju.com.br/demonstracao-caju-multibeneficios?utm_source=home_site&utm_medium=referral&utm_campaign=demonstracao_caju_multibeneficios&utm_content=video_bottom&utm_term=cta_video)
-
-O essencial
-
-[Benefícios](/plataforma/beneficios)[Premiação](/plataforma/premiacoes)[Despesas](/plataforma/despesas)[Pessoas](/plataforma/pessoas)
-
-Módulos
-
-[Bem-estar e saúde](/plataforma/saude-e-bem-estar)
-
-Soluções
-
-[Pequenas empresas](/solucoes/pequenas-empresas)[Médias empresas](/solucoes/medias-empresas)[Grandes empresas](/solucoes/grandes-empresas)
-
-Por segmentos
-
-[Indústria](/solucoes/industria)[Serviços](/solucoes/servicos)[Tecnologia](/solucoes/tecnologia)[Varejo](/solucoes/varejo)
-
-A Caju
-
-[Sobre nós](/a-caju/a-caju)[Blog](https://blog.caju.com.br/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA.)[Cajuína](https://cajuina.org/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA)[Histórias de clientes](/a-caju/historias-de-clientes)[Revenda Caju](/revenda-caju)
-
-Pacotes
-
-[Planos e pacotes](/planos)
-
-Para contratar
-
-[quero@caju.com.br](mailto:quero@caju.com.br?subject=Contato%20-%20Site)
-
-Contato
-
-[Central de ajuda](https://ajuda.caju.com.br/s/)[Fale conosco](/a-caju/fale-conosco)[Ouvidoria](/ouvidoria)
-
-Para usuários do app
-
-[oi@caju.com.br](mailto:oi@caju.com.br?subject=Contato%20-%20Site)[Telefone e Whatsapp: (11) 4118-3826](https://api.whatsapp.com/send?phone=551141183826&text=Ol%C3%A1!)
-
-Para empresas
-
-[empresas@caju.com.br](mailto:empresas@caju.com.br?subject=Contato%20-%20Site)[Chat no Portal do RH](https://empresa.caju.com.br/)
-
-Imprensa
-
-[imprensa@caju.com.br](mailto:imprensa@caju.com.br?subject=Contato%20-%20Site)
-
-Segurança e certificações
-
-[Segurança e certificações](/a-caju/seguranca-e-certificados)
-
-Seja um parceiro
-
-[Revenda Caju](/revenda-caju)
-
-Jurídico
-
-[Política de Gestão Integrada de Riscos](/juridico/politica-de-gestao-integrada-de-riscos)
-
-[Portal de privacidade](/juridico/portal-de-privacidade-caju)
-
-[Política de Prevenção à Lavagem de Dinheiro e Combate do Financiamento do Terrorismo (PLD-CFT)](/juridico/pld-cft)
-
-[Política de segurança cibernética](/juridico/politica-de-seguranca-cibernetica)
-
-[Privacidade e segurança](/juridico/privacidade-seguranca)
-
-[Política de privacidade](/juridico/privacidade)
-
-O essencial
-
-[Benefícios](/plataforma/beneficios)[Premiação](/plataforma/premiacoes)[Despesas](/plataforma/despesas)[Pessoas](/plataforma/pessoas)
-
-Módulos
-
-[Bem-estar e saúde](/plataforma/saude-e-bem-estar)
-
-Soluções
-
-[Pequenas empresas](/solucoes/pequenas-empresas)[Médias empresas](/solucoes/medias-empresas)[Grandes empresas](/solucoes/grandes-empresas)
-
-Por segmentos
-
-[Indústria](/solucoes/industria)[Serviços](/solucoes/servicos)[Tecnologia](/solucoes/tecnologia)[Varejo](/solucoes/varejo)
-
-A Caju
-
-[Sobre nós](/a-caju/a-caju)[Blog](https://blog.caju.com.br/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA.)[Cajuína](https://cajuina.org/?_gl=1*1xtcxy6*_ga*MjA3MDg3ODIxNS4xNzMwNzUzMTA0*_ga_3RPJSREWE0*czE3NjAwMjE0MTkkbzIwMSRnMCR0MTc2MDAyMTQyNSRqNTQkbDAkaDA)[Histórias de clientes](/a-caju/historias-de-clientes)[Revenda Caju](/revenda-caju)
-
-Pacotes
-
-[Planos e pacotes](/planos)
-
-Para contratar
-
-[quero@caju.com.br](#)
-
-Contato
-
-[Central de ajuda](#)[Fale conosco](/a-caju/fale-conosco)[Ouvidoria](/ouvidoria)
-
-Para usuários do app
-
-[oi@caju.com.br](mailto:oi@caju.com.br?subject=Contato%20do%20site)[Telefone e Whatsapp: (11) 4118-3826](https://api.whatsapp.com/send?phone=551141183826&text=Ol%C3%A1!)
-
-Para empresas
-
-[empresas@caju.com.br](mailto:empresas@caju.com.br?subject=Contato%20do%20site)[Chat no Portal do RH](https://empresa.caju.com.br/)
-
-Imprensa
-
-[imprensa@caju.com.br](#)
-
-Segurança e certificações
-
-[Segurança e certificações](/a-caju/seguranca-e-certificados)
-
-##### Seja um parceiro
-
-[Revenda Caju](/revenda-caju)
-
-Jurídico
-
-[Aviso de Privacidade para Consignado Privado](/juridico/aviso-de-privacidade-para-consignado-privado)
-
-[Política de Gestão Integrada de Riscos](/juridico/politica-de-gestao-integrada-de-riscos)
-
-[Portal de privacidade](/juridico/portal-de-privacidade-caju)
-
-[Política de Prevenção à Lavagem de Dinheiro e Combate do Financiamento do Terrorismo (PLD-CFT)](/juridico/pld-cft)
-
-[Política de segurança cibernética](/juridico/politica-de-seguranca-cibernetica)
-
-[Termos de uso para empresas](/juridico/termos-de-uso-para-empresas)
-
-[Termos e Condições para Uso do Pix](/juridico/termos-e-condicoes-para-uso-do-pix)
-
-[Privacidade e segurança](/juridico/privacidade-seguranca)
-
-[Política de privacidade](/juridico/privacidade)
-
-[Termos de uso colaboradores](/juridico/termos-de-uso-colaboradores)
-
-\*Oferta válida para empresas que contratarem e utilizarem o produto de multibenefícios da Caju.
-
-[
-
-](https://www.facebook.com/cajubeneficios?_rdc=2&_rdr#)[
-
-](https://www.instagram.com/caju/)[
-
-](https://www.linkedin.com/company/cajubeneficios/)[
-
-](https://www.youtube.com/c/cajubeneficios)[
-
-](https://x.com/cajubeneficios)
-
-##### Baixe nosso app
-
-[](https://apps.apple.com/br/app/caju-benef%C3%ADcios-por-inteiro/id1483671427)[](https://play.google.com/store/apps/details?id=com.caju.employeeApp&hl=pt_BR)
-
-[](/)
-
-CNPJ 33.449.007/0001-44 | Empresa Brasileira de Benefícios e Pagamentos Instituição de Pagamento Ltda
-
-A EBBP IP LTDA ("Caju") é uma Instituição de Pagamento autorizada pelo Banco Central do Brasil e atua como correspondente bancário da VIA CAPITAL - SOCIEDADE DE CRÉDITO DIRETO S.A. ("Celcoin") no produto de Empréstimo Consignado. Como correspondente bancário, a Caju segue as diretrizes da Resolução nº 4.935/21 do Banco Central do Brasil.
-
-Caju® 2026. Todos os direitos reservados
-```
-
----
-
-## Assistant (Plan · gpt-5.4 · 16.6s)
-
-_Thinking:_
-
-**Evaluating company existence**
-
-I need to answer the user's question about whether a specific company exists based on a session file discussing a startup concept. This includes components like payment processing, instant commission payouts, and analytics.
-
-Since there may not be an exact match, I should reference similar companies like DailyPay, Branch, or Caju, especially in Latin America. It could be helpful to search for Brazil-specific examples like Xerpay or SalaryFits to get a clearer idea. If necessary, I might need to gather more information online.
-
-_Thinking:_
-
-**Searching for earned wage access solutions**
-
-I want to dig deeper into the web for terms like "earned wage access Brazil" and "instant commissions" to help answer the user’s question about existing companies.
-
-While I might say pieces of this concept do exist, nothing seems to bring together all the components perfectly. I can mention several companies like DailyPay and Branch for earned wage access, or Caju and Creditas Beneficios in Brazil, but there's no exact match for what the user described. I might also reference commission software like “Everstage” or companies that handle commissions in other sectors, hinting at similar models.
-
-_Thinking:_
-
-**Exploring payout platforms**
-
-I think I might be getting closer to what the user is looking for with the idea of payouts platforms for marketplaces and direct selling companies that incorporate cards or wallets.
-
-It seems like this could fit into the concept nicely, so I’ll search for relevant solutions or companies that provide these kinds of services. This could help me give a more precise answer for the user about existing options in this space.
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.hyperwallet.com/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
- PayPal's Global Payout Capabilities | Powered by Hyperwallet
-
-[Skip to content](#content)
-
-Toggle navigation [](/)
-
-- [Documentation](https://portal.hyperwallet.com/docs)
-- [Blog](/resources/)
-- [Sales](https://www.paypal.com/us/business/contact-sales)
-- [Support](/support/)
-
-[](/)
-
-MENUMENU
-
-- [Make Payments](/make-payments/)
-- [Features](/features/)
-- [Payout Experience](/payout-experience/)
-- [Company](/company/)
-- [Developers](/developers/)
-
-[
-
-](/resources/developers-product-documentation/venmo-as-a-transfer-method/)[
-
-](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)[](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)[
-
-Which methods suit your business?
-
-](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)[
-
-PAYOUT METHODS
-
-](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)[](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)[CONTACT US](/contact-us/)[LEARN MORE](/make-payments/)
-
-PayPal’s payout capabilities help your organization send mass
-payments to contract workers, claimants, freelancers, and
-sellers around the world. Leverage Hyperwallet’s full stack
-technology to quickly and securely send commissions, rewards,
-claims, and rebates to banked and unbanked payees globally.
-
-# PAYOUTS THAT GROW
-WITH YOUR BUSINESS
-
-
-
-[CONTACT US](/contact-us/)
-
-# SEAMLESSLY
-SEND PAYOUTS
-
-
-
-## PAYOUTS THAT GROW WITH YOUR BUSINESS
-
-PayPal’s payout capabilities help your organization send mass payments to contract workers, claimants, freelancers, and sellers around the world. Leverage Hyperwallet’s full stack technology to quickly and securely send commissions, rewards, claims, and rebates to banked and unbanked payees globally.
-
-[Learn More](/make-payments/) [Contact Us](/contact-us/)[
-
-PAYOUT METHODS
-
-Which methods suit your business?
-
-
-
-](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)
-
-
-
-
-
-### Solve Payout Problems with Ease
-
-## Payout Capabilities that Help Your Business Succeed
-
-Whether you’re sending payouts to 10 payees or 10,000, PayPal can help you do it quickly, securely, and compliantly. From fast self-serve payouts for small- and medium-sized businesses, to custom configured marketplace and large enterprise integrations, PayPal’s payout capabilities are designed to handle the unique needs of your business – big or small.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-[Understand PayPal’s payout capabilities](/make-payments/)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-PAYOUT METHODS: Which methods suit your business?
-
-[Click Here](/resources/enterprises-payouts/choosing-the-right-payout-methods-for-your-payees/)
-
-### Global Payout Technology
-
-## Simplify Your Payout Process
-
-PayPal’s payout technology does more than just send payments. Our full stack approach gives organizations of all sizes the payout flexibility and control they need to streamline their operations, scale their business, and delight their payees. [View payout product features >](/features/)
-
-[](/features/)
-
-
-
-
-
-### Put Your Payees First
-
-## Own the Payout Experience
-
-Create a beautiful user experience for your payees. Highlight your brand, provide a localized UI, and differentiate your enterprise or marketplace from the competition with Hyperwallet’s Pay Portal and Embedded Payout Experiences. [View payout experiences >](/payout-experience/)
-
-[](/payout-experience/)
-
-### PAYOUT DOCUMENTATION
-
-## Explore Our Documentation & Developer Payout Tools
-
-Your developers are already responsible for building your own technology; they shouldn’t have to shoulder the burden of building payout infrastructure too. PayPal’s payout documentation and developer tools are designed to provide stakeholders with the technical and contextual information they need to integrate fast.
-
-
-
-[View developer resources](https://docs.hyperwallet.com/content/hyperwallet-payout-documentation)
-
-
-
-Streamline your global payouts.
-
-[Contact Sales](/contact-sales/)
-
-#### Get Started
-
-- [Make Payments](/make-payments/)
-- [Features](/features/)
-- [Payout Experience](/payout-experience/)
-- [Company](/company/)
-- [Developers](/developers/)
-
-- [Our FX Rates](https://paylution.com/hw2web/consumer/page/currencyCalculator.xhtml)
-- [Careers](/careers)
-- [Blog](/resources)
-
-#### Support
-
-[Hyperwallet Support Center](/support)
-
-
-#### Corporate Sales
-
-Canada/US: 1-855-787-1009
-Mon-Thu, 9am-8pm / Fri 9am-6pm EST.
-
-Australia: 1-800-729-725
-
-
-- [GitHub](https://github.com/hyperwallet)
-
-- [Accessibility](/accessibility/)
-- [Licenses and Complaints](/state-licenses/)
-- [Legal](/legal/)
-- [Privacy Policy](/privacy-policy/)
-- [Security & Compliance](/security-compliance/)
-- [Cookies](#manage-cookies)
-
-©2025 PayPal
-
-Hyperwallet is a member of the PayPal group of companies and provides services globally through its affiliates. These affiliates are regulated in various jurisdictions as follows: In Canada, by PayPal Canada Co., a registered money services business (MSB) within the Financial Transactions and Reports Analysis Centre (FINTRAC) under MSB registration: M19890412, and with Revenu Quebec under MSB license number: 12321. PayPal Canada Co. is a Nova Scotia-incorporated corporation, with its primary business address at 661 University Ave., Suite 506, Toronto, ON M5G 1M1; in the United States, through PayPal, Inc., registered with the US Financial Crimes Enforcement Network and licensed in various U.S. states as a money transmitter, NMLS ID no. 910457, with a principal address at 2211 N. First Street, San Jose, California, 95131; in Australia, through Hyperwallet Systems Australia Pty Ltd, ABN 38 616 937 716, registered with the Australian Securities and Investments Commission, Australian Financial Service Licence no. 499092, with a registered office at Level 24, 1 York Street, Sydney, NSW 2000; in the European Economic Area through PayPal (Europe) S.à r.l. et Cie, S.C.A. (R.C.S. Luxembourg B 118 349), a duly licensed Luxembourg credit institution in the sense of Article 2 of the law of 5 April 1993 on the financial sector, as amended, and under the prudential supervision of the Luxembourg supervisory authority, the Commission de Surveillance du Secteur Financier; In Singapore, through PayPal Pte. Ltd. (UEN: 200509725E), licensed by the Monetary Authority of Singapore as a major payment institution under the Payment Services Act 2019 and with its registered address at 5 Temasek Blvd #09-01, Suntec Tower Five, Singapore 038985; in the United Kingdom, through PayPal UK Ltd, authorised and regulated by the Financial Conduct Authority (FCA) as an electronic money institution under the Electronic Money Regulations 2011 for the issuance of electronic money (firm reference number 994790), in relation to its regulated consumer credit activities under the Financial Services and Markets Act 2000 (firm reference number 996405) and for the provision of Cryptocurrency services under the Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (firm reference number 1000741). Some of PayPal UK Ltd’s products including PayPal Pay in 3 and PayPal Working Capital are not regulated by the FCA.
-
-
-
-[](#page-top)
-
-- [Make Payments](/make-payments/)
-- [Features](/features/)
-- [Payout Experience](/payout-experience/)
-- [Company](/company/)
-- [Developers](/developers/)
-
-- [Documentation](https://portal.hyperwallet.com/docs)
-- [Blog](/resources/)
-- [Sales](https://www.paypal.com/us/business/contact-sales)
-- [Support](/support/)
-
-
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.payquicker.com/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
- Home - PayQuicker | Global Payout Solutions
-
-
-
-
-
-[](/)
-
-- [Products](#!)
- - [Payouts OSTurnkey integration orchestrates global payouts within your own environment.](https://payquicker.com/payouts-os/)
- - [Global Payout OrchestrationREST API plugs into our extensive network for efficient and fast payouts.](/payouts-os/#global-payout-orchestration)
- - [Real-Time PayoutsClients can payout as often as desired – daily, weekly, monthly, or even hourly.](/payouts-os/#instant-payouts)
- - [Beneficiary-Directed PaymentsPayees decide where, when, and how they want to receive funds.](/payouts-os/#beneficiary-directed-payments)
- - [Insta-PayOffer recipients earned income access with on-demand request of early pay.](/payouts-os/#insta-pay)
- - [Intelligent Payout RoutingDetermines most cost-effective channel to reduce cross-border payout expenses.](/payouts-os/#intelligent-payout-routing)
- - [Common Bank ApplicationEffortlessly get required bank approvals with a single form.](/payouts-os/#common-bank-application)
- - [PQ PortalWhite-labeled payout and debit card hosted solution](/pq-portal/)
- - [Global Payout OrchestrationREST API plugs into our extensive network for efficient and fast payouts.](/pq-portal/#global-payout-orchestration)
- - [Beneficiary-Directed PaymentsPayees decide where, when, and how they want to receive funds.](/pq-portal/#beneficiary-directed-payments)
- - [Intelligent Payout RoutingDetermines most cost-effective channel to reduce cross-border payout expenses.](/pq-portal/#intelligent-payout-routing)
- - [Seamless Brand ExperienceClient-branded solutions promote and recruit with every login, transaction, and swipe](/pq-portal/#seamless-brand-experience)
- - [Common Bank ApplicationEffortlessly get required bank approvals with a single form.](/pq-portal/#common-bank-application)
- - [Real-Time PayoutsClients can payout as often as desired – daily, weekly, monthly, or even hourly.](/pq-portal/#instant-payouts)
- - [Tax As-A-ServiceSave time, money, and hassle with our US and Canadian Tax Services.](/pq-portal/#tax-as-a-service)
- - [KYC As-A-ServiceProtect your payees and their funds with automated ID verification.](/pq-portal/#kyc-as-a-service)
-- [Dev Center](https://payquicker.com/dev-center/)
-- [Solutions](#)
- - [Accounts Payable & Corporate PayoutsSeamlessly remit corporate payables to suppliers and vendors](https://payquicker.com/accounts-payable/)
- - [Affiliate & Influencer PayoutsKeep affiliate marketers engaged with real-time payments](https://payquicker.com/affiliate-influencer-networks/)
- - [Clinical TrialsInstantly pay stipends & reimbursements to clinical trial participants](https://payquicker.com/clinical-trials/)
- - [Direct Selling PayoutsPay distributors instantly with the industry-leading commission payment solution](https://payquicker.com/direct-selling/)
- - [Instant eSports Payouts and Gaming Rewards Made EasyEffortlessly pay out winnings & disburse rewards in real-time](https://payquicker.com/gaming-rewards/)
- - [Freelance and Gig Jobs Payout PlatformProvide instant gratification to gig workers & freelancers](https://payquicker.com/gig-economy-platforms/)
- - [Insurance Claims PayoutsStreamline payouts process from agent commissions to claim payments](https://payquicker.com/insurance-claims/)
- - [Interviews, Focus Groups, SurveysInstantly send funds to research participants around the globe in real-time](https://payquicker.com/interviews-focus-groups-surveys/)
- - [NIL PayoutsSimplify payouts to athletes for Name, Image, and Likeness (NIL) deals](https://payquicker.com/nil-platforms/)
-- [Company](https://payquicker.com/company-new/)
- - [Who We Are](/company-new/#who-we-are)
- - [Meet The Team](/company-new/#meet-the-team)
- - [Trust Center](https://payquicker.com/trust-center/)
- - [PayQuicker Insights](https://payquicker.com/resources/)
- - [Case Studies](https://payquicker.com/case-studies/)
- - [Become a Partner](/company-new/#become-a-partner)
- - [Careers](/company-new/#careers)
--
-
-- [Contact Us](https://payquicker.com/contact-us/)
-- [Help Center](https://payquicker.com/help-center/)
-
-# Global Payouts Orchestration
-
-## Built For Businesses. Empowering Payees.
-
-Smarter, faster, seamless real-time payouts built for the next generation of global businesses. One API connection unlocks instant access to leading payment systems and diverse payment methods—intelligently delivered in a white-labeled payee experience.
-
-Orchestrating the future of global payments, today.
-
-[Book a Demo 
-
-](/contact-us/)
-
-## Best in Class Partners
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-### Leading the Industry
-
-18+
-
-Years In Business
-
-210+
-
-Countries & Territories
-
-80+
-
-Currencies
-
-200+
-
-Global Orchestration Partners
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Global Payouts Orchestration
-
-Seamless payouts for businesses to anyone, anywhere. **Our single API connects to multiple banks and global payment rails**, optimizing every transaction for speed, cost, or both. Real-time payouts, tailored to your needs.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Empowered Payees
-
-Put payees in charge. **From cards to mobile wallets, cash, or checks, payees choose how and when to get paid.** With support for 80+ currencies, we ensure flexibility for every industry, region, and demographic.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Insta-Pay, Access to Earned Wages
-
-**Empower your workforce with on-demand earned wage access.** Offer employees instant payouts of their earnings, fostering financial well-being, satisfaction, and loyalty.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Smarter Payments, Faster Access
-
-Our intelligent routing reduces fees and inefficiencies, delivering faster payouts through the most cost-effective channels. **Pay instantly, hourly, daily, or as needed while keeping costs low and payees happy.**
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### PayQuicker Flex
-
-PayQuicker’s Flex solution delivers the benefits of stablecoins with the simplicity and speed your business needs. Instantly pay in over 60 currencies across 210+ countries and territories through one trusted, compliant partner with no crypto or extra integrations required.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Your Brand, Front and Center
-
-Elevate your brand at every step. **Offer payees branded debit cards, customizable portals, and mobile apps.** Or use Payouts OS for seamless payouts under your domain.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### In-House Customer Support
-
-Deliver peace of mind with **top-tier, multilingual customer support in over 18 languages.** Ensure seamless assistance for payees worldwide, keeping operations smooth and payees satisfied.
-
-
-
-
-
-## OUR FEATURES
-
-### Solving the Global Payout Challenge
-
-#### Simplified Global Scaling
-
-Ditch the paperwork. With one **streamlined application**, gain access to 200+ banking partners and start global payouts faster.
-
-
-
-
-
-
-
-## HOW WE PARTNER WITH YOU
-
-### Payouts Built for You and Your Payees
-
-
-
-
-
-01
-
-#### Tailor Your Solution
-
-Choose the features and payout options that fit your business needs. From flexible payment methods to branded experiences, we’ve got you covered.
-
-02
-
-#### Seamlessly Onboard Payees
-
-Easily onboard payees, streamline KYC processes, and provide them with flexible local payout choices – all through our user-friendly platform.
-
-03
-
-#### Send Payments Effortlessly
-
-Make real-time global payouts your way. Choose bulk uploads, process single payments, or seamlessly integrate with our API.
-
-
-
-## Industries
-
-Seamless payout solutions for diverse industries, from corporate and affiliate to gaming, freelance, and more.
-
-[
-
-
-
-
-
-Accounts Payable and Corporate Payouts
-
-
-
-
-
-
-
-](/accounts-payable/)
-
-[
-
-
-
-
-
-Affiliate & Influencer Payouts
-
-
-
-
-
-
-
-](/affiliate-influencer-networks/)
-
-[
-
-
-
-
-
-Clinical Trials
-
-
-
-
-
-
-
-](/clinical-trials/)
-
-[
-
-
-
-
-
-Direct Selling Payouts
-
-
-
-
-
-
-
-](/direct-selling/)
-
-[
-
-
-
-
-
-Instant Gaming & Rewards Payouts
-
-
-
-
-
-
-
-](/gaming-rewards/)
-
-[
-
-
-
-
-
-Gig Workers Payouts
-
-
-
-
-
-
-
-](/gig-economy-platforms/)
-
-[
-
-
-
-
-
-Insurance Claims Payouts
-
-
-
-
-
-
-
-](/insurance-claims/)
-
-[
-
-
-
-
-
-Interviews, Focus Groups, Surveys
-
-
-
-
-
-
-
-](/interviews-focus-groups-surveys/)
-
-[
-
-
-
-
-
-NIL Payouts
-
-
-
-
-
-
-
-](/nil-platforms/)
-
-## BUILT FOR DEVELOPERS
-
-### Seamless Integration, Lightning-Fast Deployment
-
-We make it easy for your dev team to integrate and launch. With direct access to our experts, documentation, and hands-on support at every step, you’ll have the flexibility to build, customize, and scale with ease. Less friction, more innovation.
-
-[Explore APIs Guide](https://payquicker.com/dev-center/)
-
-## Real Results, Real Voices
-
-
-
-
-
-
-
-
-
-“PayQuicker has been an exceptional partner for [MONAT](https://monatglobal.com/) as we manage commission payouts to Market Partners across more than a dozen countries. Their platform is reliable and their team is incredibly responsive, especially when time-sensitive situations arise. On multiple occasions they have gone the extra mile to help us resolve escalations quickly, ensuring our payouts remain smooth and on schedule. That level of service and partnership is invaluable to our business.”
-
-
-
-
-
-Monat
-
-Ryan Miles,Vice President – Commissions and Risk
-
-
-
-
-
-“If we weren’t able to partner with PayQuicker for our expansion plan in Europe, we wouldn’t have the presence that we currently have. PayQuicker’s robust payout orchestration platform provided the seamless, scalable solution we needed to continue our growth across new markets.”
-
-
-
-
-
-Immunotec
-
-Luis Ascencio, CEO
-
-
-
-
-
-“People just want to have access to their money as fast as possible. This is where PayQuicker came in. It’s fast, it’s reliable and, of course our MKX branded, VISA card adds credibility to the whole opportunity. I would recommend PayQuicker to anyone that wants peace of mind. It’s an amazing partnership and I wish that all of my partnerships were as easy as the one we have with PayQuicker.”
-
-
-
-
-
-MKX
-
-Roal Mailly, Founder & CEO
-
-
-
-
-
-“If I can’t pay my people, nothing good will happen, so I rely on payouts, it’s the lifeblood of my business! It is not easy to be successful but it is easier when you have trusted partners that engage with you and work together with you. I’ll remember PayQuicker because of what they did for us when no other vendor could meet our needs.”
-
-
-
-
-
-Limbic Arc
-
-George Wright, CEO
-
-
-
-
-
-
-
-
-
-“The support and attention we receive from PayQuicker is unparalleled. Their attentiveness to our needs along with their willingness to help make our Designers happy is very refreshing. Being able to have a partner that I can confidently put my trust in to work directly with our Designers and internal staff members makes me feel like they are an extension of our internal team. We have definitely chosen the right partner with PayQuicker.”
-
-
-
-
-
-Think Goodness
-
-Kathryn Dunn, Controller
-
-
-
-
-
-
-
-
-
-“When we founded Curated in September 2012, our mission was not only to uplift, empower, and validate women across the globe but also change the way commissions were being paid out. Our partnership with PayQuicker has allowed us to pay commission to our Presenters within three hours of making a sale, completely changing the traditional commission payment paradigm. As we continue to expand aggressively, PayQuicker has been there every step of the way. We cannot think of a better payment solutions partner than PayQuicker.”
-
-
-
-
-
-Curated
-
-Derek Maxfield, CEO & President
-
-
-
-
-
-
-
-
-
-“Nice and Bella provides jewelry to hundreds of independent distributors in USA. It’s important for us to be sure that our distributors receive their commissions on time. PayQuicker has been our trusted partner for the last 3 years. They are always there to assist us in an efficient and professional manner. Thank you PayQuicker. We are grateful for your service and assistance.”
-
-
-
-
-
-Nice & Bella
-
-Maritza Garcia, Accounting
-
-
-
-
-
-
-
-
-
-“Working with PayQuicker was a natural choice, as their experience in bringing streamlined and secure payments to valued brand representatives is unmatched.”
-
-
-
-
-
-MeAmora
-
-Ashley Ferguson, General Manager
-
-
-
-
-
-
-
-
-
-“In my role, I have the opportunity to work with many suppliers, vendors, and other third-party providers. I can honestly say that Crystal Holtzendorff and Nicole Kessler from PayQuicker have been among the very best. They are kind, attentive, responsive, and willing to step in and get their hands dirty when needed. Their turn around time has been on point and their communication has been flawless.”
-
-
-
-
-
-Melaleuca
-
-Jake Mangum,Vice President, International
-
-
-
-
-
-
-
-
-
-“PayQuicker has provided a wonderful solution to my growing payroll! Not only have the expenses due to processing been decreased considerably when compared to more conventional payroll systems, their implementation and integration procedures are second to none. Crystal, Steve and Nicole have turned, what can be a stressful process, into a seamless and easily managed experience. Kudos to their wonderful team!”
-
-
-
-
-
-NuLifeSpan RX
-
-J.D.,CEO
-
-
-
-
-
-
-
-
-
-## WHY PAYQUICKER
-
-### Payouts, Simplified
-
-We take the hard work out of making payments.
-
-
-
-
-
-Global Payout Network
-
-Pay to 210+ countries & territories in 80+ currencies through our global network of established providers, networks, processors, and banks.
-
-
-
-
-
-Secure & Compliant
-
-Reduce risk and eliminate liability with our PCI-compliant security. Payees easily onboard themselves to the system, relieving your team of the burden of identity verification and secure data collection.
-
-
-
-
-
-Flexible Configuration
-
-Power your business with our award-winning FinTech solutions that can be customized to meet your unique payment needs.
-
-
-
-
-
-Multilingual Customer Support
-
-Our full in-house customer support team is available by phone, live chat, and email in 18+ languages to ensure all client and payee inquiries are promptly resolved.
-
-[Book a Demo 
-
-](/contact-us/)
-
-## PayQuicker Insights
-
-Hear from our experts on the latest news and trends shaping the global payouts industry.
-
-[
-
-
-
-
-
-March 11, 2026
-
-PayQuicker Launches 1099 Tax Solution Powered by Avalara
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/payquicker-launches-1099-solution-powered-by-avalara/)
-
-[
-
-
-
-
-
-March 6, 2026
-
-Payee Experiences: Why They Matter in Modern Global Payouts
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/payee-experiences/)
-
-[
-
-
-
-
-
-March 5, 2026
-
-Cross-Border Payment Platform: Replacing Legacy Banking
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/cross-border-payment-platform/)
-
-[
-
-
-
-
-
-March 3, 2026
-
-PayQuicker’s New Whitepaper: Turning Global Payouts into a Growth Strategy
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/payquickers-new-whitepaper-turning-global-payouts-into-a-growth-strategy/)
-
-[
-
-
-
-
-
-February 27, 2026
-
-Clinical Trial Participants’ Experience: The Payee Perspective
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/clinical-trial-participants-experience/)
-
-[
-
-
-
-
-
-February 24, 2026
-
-Global Affiliates Deserve Local Payouts: Pay Smarter with PayQuicker
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/global-affiliates-deserve-local-payouts-pay-smarter-with-payquicker/)
-
-[
-
-
-
-
-
-February 10, 2026
-
-Affiliate Payouts and Payments Trends to Watch in 2026
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/affiliate-payouts-trends-2026/)
-
-[
-
-
-
-
-
-February 4, 2026
-
-Clinical Trials Payouts Trends Shaping Research Through 2026
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/clinical-trials-payouts-trends-2026/)
-
-[
-
-
-
-
-
-January 29, 2026
-
-PayQuicker Nears $1B in Global Payouts as Demand for Real-Time, Flexible Payments Accelerates
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/payquicker-nears-1b-in-global-payouts-as-demand-for-real-time-flexible-payments-accelerates/)
-
-[
-
-
-
-
-
-January 28, 2026
-
-PayQuicker Pulse | 2025 Q4 Newsletter
-
-Learn More
-
-
-
-
-
-](https://payquicker.com/payquicker-pulse-2025-q4-newsletter/)
-
-
-
-
-
-
-
-
-
-
-
-### Get Started with PayQuicker Today
-
-[Book a Demo ](/contact-us/)
-
-
-
-Products
-
-[Payouts OS](https://payquicker.com/payouts-os/)
-
-[Custom Payouts With PQ Portal](https://payquicker.com/pq-portal/)
-
-[Dev Center](https://payquicker.com/dev-center/)
-
-[Documentation](https://payquickerv101152018.docs.apiary.io/)
-
-Solutions
-
-[Accounts Payable & Corporate Payouts](https://payquicker.com/accounts-payable/)
-
-[Affiliate & Influencer Payouts](https://payquicker.com/affiliate-influencer-networks/)
-
-[Clinical Trials](https://payquicker.com/clinical-trials/)
-
-[Direct Selling Payouts](https://payquicker.com/direct-selling/)
-
-[Instant eSports Payouts and Gaming Rewards Made Easy](https://payquicker.com/gaming-rewards/)
-
-[Freelance and Gig Jobs Payout Platform](https://payquicker.com/gig-economy-platforms/)
-
-[Insurance Claims Payouts](https://payquicker.com/insurance-claims/)
-
-[Instant Payout for Surveys, Focus Groups, and Interviews](https://payquicker.com/interviews-focus-groups-surveys/)
-
-Company
-
-[Who We Are](/company-new/#who-we-are)
-
-[Become a Partner](/company-new/#become-a-partner)
-
-[Careers](/company-new/#careers)
-
-[PayQuicker Insights](https://payquicker.com/resources/)
-
-[Trust Center](https://payquicker.com/trust-center/)
-
-[Help Center](https://payquicker.com/help-center/)
-
-[Contact Us](https://payquicker.com/contact-us/)
-
-Quick Links
-
-[Privacy Policy](https://payquicker.com/privacy-policy/)
-
-[Data Privacy Framework Policy](https://payquicker.com/dpf-policy/)
-
-[Cookie Policy](https://payquicker.com/cookie-policy/)
-
-[Convera Disclosure](https://convera.com/compliance-legal/partner-channel-disclosures/)
-
-
-
-
-
-
-
-
-
----
-
-© Copyright 2023. All Rights Reserved.
-
-[](https://www.facebook.com/PayQuickerGlobal/)
-
-[](https://twitter.com/PayQuicker)
-
-[](https://www.instagram.com/payquicker/)
-
-[](https://www.linkedin.com/company/payquicker-llc/)
-
-
-
-
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://xerpay.com.br/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Error:**
-```
-Error: Unable to connect. Is the computer able to access the url?
-```
-
-**Tool: webfetch**
-
-**Input:**
-```json
-{
- "url": "https://www.dock.tech/",
- "format": "markdown",
- "timeout": 20
-}
-```
-
-**Output:**
-```
- Dock - Spread financial power
-
-
-
-
-
-
-
-
-
-[Dock](https://dock.tech)
-
-[A Dock](#!) [Soluções](#!) [Developers](https://developers.dock.tech/) [Conteúdo](https://dock.tech/fluid/) [Contato](#!)
-
-[](# "Clique para buscar")
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-**A Dock**
-
-Há mais de 25 anos cumprindo a missão de democratizar o acesso a serviços financeiros.
-
-[Sobre](https://dock.tech/sobre/)
-
-Desmaterializamos o universo financeiro para impulsionar a sociedade.
-
-[Carreira na Dock](https://dock.tech/carreira/)
-
-Libere o seu potencial máximo e sem fronteiras, crie soluções inovadoras para grandes marcas.
-
-[Sala de Imprensa](https://dock.tech/sala-de-imprensa/)
-
-Comunicando nosso real impacto e propósito de inclusão financeira. Acesse notícias e recursos oficiais.
-
-**Soluções**
-
-Conte com o maior portfólio de soluções financeiras do Brasil para expandir e fortalecer seu negócio.
-
-[Banking](https://dock.tech/solucao/banking)
-
-Crie seu próprio banco digital e ofereça meios de pagamento como Pix.
-
-[Cards & Credit](https://dock.tech/solucao/cards-credit)
-
-Ofereça cartões com sua marca: crédito, débito, global, benefícios e mais.
-
-[Acquiring](https://dock.tech/solucao/acquiring)
-
-Adquirência white label de ponta a ponta para transformar seu negócio.
-
-[Fraud Prevention](https://dock.tech/solucao/fraud-prevention)
-
-Autenticação, detecção e prevenção de riscos na jornada de seu cliente.
-
-[Nossa Plataforma](https://dock.tech/dock-one/)
-
-Plataforma completa para escalar sua operação com alcance global.
-
-[Soluciones LATAM](https://dock.tech/soluciones-dock-latam/)
-
-Impulse la innovación y lleve su negocio más lejos.
-
-[Soluciones Brasil](#!)
-
-Conozca el portafolio más completo de servicios financieros.
-
-[Dock One](https://dock.tech/dock-one/)
-
-Una plataforma completa para escalar tus operaciones con alcance global.
-
-[Banking](https://dock.tech/solucao/banking)
-
-Crie seu próprio banco digital e ofereça meios de pagamento como Pix.
-
-[Cards & Credit](https://dock.tech/solucao/cards-credit)
-
-Ofereça cartões com sua marca: crédito, débito, global, benefícios e mais.
-
-[Acquiring](https://dock.tech/solucao/acquiring)
-
-Adquirência white label de ponta a ponta para transformar seu negócio.
-
-[Fraud Prevention](https://dock.tech/solucao/fraud-prevention)
-
-Autenticação, detecção e prevenção de riscos na jornada de seu cliente.
-
-[Nossa Plataforma](https://dock.tech/dock-one/)
-
-Plataforma completa para escalar sua operação com alcance global.
-
-[Conta Digital](https://dock.tech/solucao/banking/#conta-digital) [Pix](https://dock.tech/solucao/banking/#pix) [Boletos](https://dock.tech/solucao/banking/#boletos) [Marketplace de Vouchers e Recargas](https://dock.tech/solucao/banking/#marketplace)
-
-[Processamento de Cartões](https://dock.tech/solucao/cards-credit/#processamento) [Licença de Bandeira](https://dock.tech/solucao/cards-credit/#bandeiras) [Cartão de Crédito](https://dock.tech/solucao/cards-credit/#cartao-de-credito) [Cartão Private Label](https://dock.tech/solucao/cards-credit/#cartao-private-label) [Cartão Multibenefícios](https://dock.tech/solucao/cards-credit/cartao-multibeneficios/) [Cartão Global](https://dock.tech/solucao/cards-credit/#cartao-global) [Cartão Pré-Pago e Débito](https://dock.tech/solucao/cards-credit/#cartao-pre-debito) [Cartão Consignado](https://dock.tech/solucao/cards-credit/#cartao-consignado) [Tokenização](https://dock.tech/tokenizacao/)
-
-[Acquiring as a service](https://dock.tech/solucao/acquiring)
-
-[Autenticação Biométrica](https://dock.tech/solucao/fraud-prevention/#biometria) [Background Check](https://dock.tech/solucao/fraud-prevention/#background-check) [Antifraude transacional](https://dock.tech/solucao/fraud-prevention/#antifraude-transacional) [Comunicação Multicanal](https://dock.tech/solucao/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One](https://dock.tech/dock-one) [Plataforma de Dados](https://dock.tech/plataforma-de-dados)
-
-[Soluciones LATAM](https://dock.tech/soluciones-dock-latam/) [Dock Colômbia](https://dock.tech/paises/colombia/) [Dock México](https://dock.tech/paises/mexico/)
-
-[Banking](https://dock.tech/solucao/banking) [Cards & Credit](https://dock.tech/solucao/cards-credit) [Acquiring](https://dock.tech/solucao/acquiring) [Fraud Prevention](https://dock.tech/solucao/fraud-prevention)
-
-[Dock One](https://dock.tech/dock-one) [Plataforma de Dados](https://dock.tech/plataforma-de-dados)
-
-[Conta Digital](https://dock.tech/solucao/banking/#conta-digital) [Pix](https://dock.tech/solucao/banking/#pix) [Boletos](https://dock.tech/solucao/banking/#boletos) [Marketplace de Vouchers e Recargas](https://dock.tech/solucao/banking/#marketplace)
-
-[Processamento de Cartões](https://dock.tech/solucao/cards-credit/#processamento) [Licença de Bandeira](https://dock.tech/solucao/cards-credit/#bandeiras) [Cartão de Crédito](https://dock.tech/solucao/cards-credit/#cartao-de-credito) [Cartão Private Label](https://dock.tech/solucao/cards-credit/#cartao-private-label) [Cartão Multibenefícios](https://dock.tech/solucao/cards-credit/cartao-multibeneficios/) [Cartão Global](https://dock.tech/solucao/cards-credit/#cartao-global) [Cartão Pré-Pago e Débito](https://dock.tech/solucao/cards-credit/#cartao-pre-debito) [Cartão Consignado](https://dock.tech/solucao/cards-credit/#cartao-consignado) [Tokenização](https://dock.tech/tokenizacao/)
-
-[Acquiring as a service](https://dock.tech/solucao/acquiring)
-
-[Autenticação Biométrica](https://dock.tech/solucao/fraud-prevention/#biometria) [Background Check](https://dock.tech/solucao/fraud-prevention/#background-check) [Antifraude transacional](https://dock.tech/solucao/fraud-prevention/#antifraude-transacional) [Comunicação Multicanal](https://dock.tech/solucao/fraud-prevention/#comunicacao-multicanal)
-
-[Dock One](https://dock.tech/dock-one) [Plataforma de Dados](https://dock.tech/plataforma-de-dados)
-
-**Contato**
-
-Nós estamos preparados para atende-lo da melhor forma possível.
-
-[Atendimento ao consumidor](https://dock.tech/sac/)
-
-Para dúvidas frequentes e serviço de atendimento ao consumidor, clique aqui.
-
-[Atendimento à Imprensa](https://dock.tech/sala-de-imprensa/#contato-imprensa)
-
-Entre em contato com nosso time de comunicação.
-
-[Dock](https://dock.tech)
-
-[
-
-
-
-
-
-
-
-](#!)
-
-[A Dock](#!) [Soluções](#!) [Partners](https://dock.tech/partners) [Developers](https://developers.dock.tech/) [Conteúdo](https://dock.tech/fluid/) [Contato](#!)
-
-[A Dock](#!)
-
-Há mais de 25 anos cumprindo a missão de democratizar o acesso a serviços financeiros.
-
-[Sobre](https://dock.tech/sobre/)
-
-Desmaterializamos o universo financeiro para impulsionar a sociedade.
-
-[Carreira na Dock](https://dock.tech/carreira/)
-
-Libere o seu potencial máximo e sem fronteiras, crie soluções inovadoras para grandes marcas.
-
-[Sala de Imprensa](https://dock.tech/sala-de-imprensa/)
-
-Comunicando nosso real impacto e propósito de inclusão financeira. Acesse notícias e recursos oficiais.
-
-[Soluções](#!)
-
-Conte com o maior portfólio de soluções financeiras do Brasil para expandir e fortalecer seu negócio.
-
-[Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Conheça nossa plataforma](#!) [Soluciones LATAM](#!) [Soluciones Brasil](#!) [Dock One](#!) [Banking](#!) [Cards & Credit](#!) [Acquiring](#!) [Fraud Prevention](#!) [Conheça nossa plataforma](#!)
-
-[Soluciones LATAM](#!)
-
-Impulse la innovación y lleve su negocio más lejos.
-
-[Soluciones LATAM](https://dock.tech/es/soluciones-dock-latam/)
-
-[Soluciones Brasil](#!)
-
-Conozca el portafolio más completo de servicios financieros.
-
-[Banking](https://dock.tech/solucao/banking) [Cards & Credit](https://dock.tech/solucao/cards-credit) [Acquiring](https://dock.tech/solucao/acquiring) [Fraud Prevention](https://dock.tech/solucao/fraud-prevention)
-
-[Banking](#!)
-
-Crie seu próprio banco digital e ofereça meios de pagamento como Pix.
-
-[Conta Digital](https://dock.tech/solucao/banking/#conta-digital) [Pix](https://dock.tech/solucao/banking/#pix) [Boletos](https://dock.tech/solucao/banking/#boletos) [Marketplace de Vouchers e Recargas](https://dock.tech/solucao/banking/#marketplace)
-
-[Cards & Credit](#!)
-
-Ofereça cartões com sua marca: crédito, débito, global, benefícios e mais.
-
-[Processamento de Cartões](https://dock.tech/solucao/cards-credit/#processamento) [Licença de Bandeira](https://dock.tech/solucao/cards-credit/#bandeiras) [Cartão de Crédito](https://dock.tech/solucao/cards-credit/#cartao-de-credito) [Cartão Private Label](https://dock.tech/solucao/cards-credit/#cartao-private-label) [Cartão Multibenefícios](https://dock.tech/solucao/cards-credit/#cartao-multibeneficio) [Cartão Global](https://dock.tech/solucao/cards-credit/#cartao-global) [Cartão Pré-Pago e Débito](https://dock.tech/solucao/cards-credit/#cartao-pre-debito) [Cartão Consignado](https://dock.tech/solucao/cards-credit/#cartao-consignado)
-
-[Acquiring](#!)
-
-Adquirência white label de ponta a ponta para transformar seu negócio.
-
-[Acquiring as a service](https://dock.tech/solucao/acquiring)
-
-[Fraud Prevention](#!)
-
-Autenticação, detecção e prevenção de riscos na jornada de seu cliente.
-
-[Autenticação Biométrica](https://dock.tech/solucao/fraud-prevention/#biometria) [Background Check](https://dock.tech/solucao/fraud-prevention/#background-check) [Antifraude transacional](https://dock.tech/solucao/fraud-prevention/#antifraude-transacional) [Comunicação Multicanal](https://dock.tech/solucao/fraud-prevention/#comunicacao-multicanal)
-
-[Nossa plataforma](#!)
-
-Plataforma completa para escalar sua operação com alcance global.
-
-
-
-
-
-DOCK ONE **Nossas soluções por camada**
-
-Plataforma robusta de alta tecnologia, totalmente personalizada e modular graças a nossas APIs, além de cuidarmos de toda a burocracia, TI, produtos, regulatório, licenças e prevenção à fraude.
-
-[SAIBA MAIS](https://dock.tech/dock-one)
-
-[Contato](#!)
-
-Nós estamos preparados para atende-lo da melhor forma possível.
-
-[Atendimento ao Consumidor](https://dock.tech/sac/)
-
-Para dúvidas frequentes e serviço de atendimento ao consumidor, clique aqui.
-
-[Atendimento à Imprensa](https://dock.tech/sala-de-imprensa/#contato-imprensa)
-
-Entre em contato com nosso time de comunicação.
-
-# A mais completa infraestrutura de serviços financeiros
-para o seu negócio
-
-Ofereça conta digital, cartões com sua marca e inove em serviços de meios de pagamentos com o Pix e adquirência. Tudo com segurança e prevenção à fraude.
-
-[SAIBA MAIS](#spread-power "Clique para acessar")
-
-Your browser does not support the video tag.
-
-## Spread financial power
-
-Faça parte da maior transformação já vista em serviços financeiros e impulsione seu negócio espalhando o poder das finanças pelo mundo.
-
-### Dock One
-
-Explore nossa plataforma cloud native, a maior e mais completa da América Latina e conheça nossas soluções.
-
-[Saiba mais](https://dock.tech/dock-one/ "Clique e saiba mais")
-
-
-
-
-
-### Banking
-
-Eleve a experiência do cliente e aumente sua rentabilidade com soluções financeiras integradas ao seu core business.
-
-[Saiba mais]( https://dock.tech/solucao/banking/ "Clique e saiba mais")
-
-
-
-
-
-### Cards & Credit
-
-Ofereça cartões personalizados com sua marca das principais bandeiras, enquanto cuidamos de toda a operação.
-
-[Saiba mais](https://dock.tech/solucao/cards-credit "Clique e saiba mais")
-
-
-
-
-
-### Acquiring
-
-Tenha sua própria solução de adquirência white label, usando a nossa tecnologia, para garantir simplicidade e rapidez no go-to-market.
-
-[Saiba mais](https://dock.tech/solucao/acquiring "Clique e saiba mais")
-
-
-
-
-
-### Fraud Prevention
-
-Reduza o risco de ponta a ponta em seu modelo de negócio de banking, cards ou acquiring por meio de soluções que vão do onboarding de clientes ao monitoramento de transações.
-
-[Saiba mais](https://dock.tech/solucao/fraud-prevention/ "Clique e saiba mais")
-
-
-
-
-
-### Líder en tecnología financiera en América Latina.
-
-Sea parte de la mayor revolución jamás vista en servicios financieros, descubra cómo nuestras soluciones integradas pueden impulsar su negocio.
-
-[Conozca nuestras soluciones](https://dock.tech/soluciones-dock-latam/ "Clique e saiba mais")
-
-
-
-
-
-### Dock One
-
-Explore nuestra plataforma cloud native, la mayor y más completa de América Latina, y conozca nuestras soluciones.
-
-[CONOZCA MÁS](https://dock.tech/es/dock-one/ "Clique e saiba mais")
-
-Your browser does not support the video tag.
-
-### Dock One
-
-Explore nossa plataforma cloud native, a maior e mais completa da América Latina e conheça nossas soluções.
-
-[Saiba mais](https://dock.tech/dock-one/ "Clique e saiba mais")
-
-
-
-
-
-### Banking
-
-Eleve a experiência do cliente e aumente sua rentabilidade com soluções financeiras integradas ao seu core business.
-
-[Saiba mais]( https://dock.tech/solucao/banking/ "Clique e saiba mais")
-
-
-
-
-
-### Cards & Credit
-
-Ofereça cartões personalizados com sua marca das principais bandeiras, enquanto cuidamos de toda a operação.
-
-[Saiba mais](https://dock.tech/solucao/cards-credit "Clique e saiba mais")
-
-
-
-
-
-### Acquiring
-
-Tenha sua própria solução de adquirência white label, usando a nossa tecnologia, para garantir simplicidade e rapidez no go-to-market.
-
-[Saiba mais](https://dock.tech/solucao/acquiring "Clique e saiba mais")
-
-
-
-
-
-### Fraud Prevention
-
-Reduza o risco de ponta a ponta em seu modelo de negócio de banking, cards ou acquiring por meio de soluções que vão do onboarding de clientes ao monitoramento de transações.
-
-[Saiba mais](https://dock.tech/solucao/fraud-prevention/ "Clique e saiba mais")
-
-
-
-
-
-## Conte com mais de 20 anos de experiência da verdadeira one-stop-shop em serviços financeiros
-
-
-
-
-
-CARTÕES **R$ 1,4 trilhão**
-
-processado anualmente
-
-
-
-
-
-CARTÕES
-
-Emissor de cartão de **crédito, débito e
-pré-pago**
-
-
-
-
-
-PLATAFORMA COMPLETA **56**
-
-é o número de operações financeiras processadas pela Dock enquanto você lê esse card
-
-
-
-
-
-CONTA DIGITAL **70**
-
-milhões de contas ativas nos últimos 30 dias
-
-
-
-
-
-DOCK **Presente em 11 países**
-
----
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**La evolución de la tecnología financiera en América Latina.**
-
-
-
-
-
-PIX **1,3**
-
-bilhão de Pix realizados nos últimos 12 meses
-
----
-
-
-
-
-
-DOCK **+400**
-
-Empresas líderes de mercado confiam na Dock
-
-
-
-
-
-ACQUIRING **+30**
-
-bandeiras homologadas: Visa, Mastercard, Elo, Amex e muito mais!
-
-
-
-
-
----
-
-
-
-
-
-BANKING
-
-**Provedor** de infraestrutura para pagamentos e banking
-
-**Provedor** de infraestrutura para pagamentos e banking
-
-**Proveedor** de infraestructura de pagos con un conjunto completo de soluciones.
-
-
-
-
-
-DOCK ONE **Nossas soluções por camada**
-
-Plataforma robusta de alta tecnologia, totalmente personalizada e modular graças a nossas APIs, além de cuidarmos de toda a burocracia, TI, produtos, regulatório, licenças e prevenção à fraude.
-
-
-
-
-
-ACQUIRING **+30**
-
-bandeiras homologadas: Visa, Mastercard, Elo, Amex e muito mais!
-
-
-
-
-
----
-
-
-
-
-
-BANKING **Provedor**
-
-de infraestrutura para pagamentos e banking
-
-
-
-
-
-DOCK ONE **Nossas soluções por camada**
-
-Plataforma robusta de alta tecnologia, totalmente personalizada e modular graças a nossas APIs, além de cuidarmos de toda a burocracia, TI, produtos, regulatório, licenças e prevenção à fraude.
-
-
-
-
-
-PIX **1,3**
-
-bilhão de Pix realizados nos últimos 12 meses
-
-
-
-
-
-CARTÕES **R$ 1,4 trilhão**
-
-processado anualmente
-
-
-
-
-
-CARTÕES
-
-Emissor de cartão de **crédito, débito e pré-pago**
-
-
-
-
-
-PLATAFORMA COMPLETA **56**
-
-é o número de operações financeiras processadas pela Dock enquanto você lê esse card
-
-
-
-
-
-CONTA DIGITAL **70**
-
-milhões de contas ativas nos últimos 30 dias
-
-
-
-
-
-DOCK **Presente em 11 países**
-
----
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**IP regulada e participante direto Pix** (código bancário #301)
-
-**La evolución de la tecnología financiera en América Latina.**
-
-**
-
-
-
-
-
-DOCK **400**
-
-Clientes aproximadamente
-
-
-
-**
-
- **
-
-
-
-## Confiabilidade e segurança para suas transações
-
-Ao escolher a Dock, você não está apenas selecionando um serviço; você está escolhendo um parceiro dedicado a alavancar o seu sucesso.
-
-
-
-
-
-### IP Regulada e participante direto Pix
-
-Tranquilidade em saber que seus pagamentos estão em boas mãos, com total segurança e respaldo legal.
-
-
-
-
-
-### Licenças VISA, Master, Elo
-
-Aceite as principais bandeiras de cartão do mercado e ofereça mais opções para seus clientes.
-
-
-
-
-
-### Plataforma de pagamentos global adaptável
-
-Alcance clientes em todo o mundo e personalize a experiência de acordo com suas necessidades.
-
-
-
-
-
-### Infraestrutura abrangente
-
-Solução completa para pagamentos online, incluindo gateway, antifraude e gestão de risco.
-
-
-
-
-
-### Certificações Reconhecidas
-
-Compromisso com a segurança, a qualidade e a conformidade internacional em todas as nossas operações.
-
-
-
-
-
-### Prevenção a Fraudes
-
-Dados e transações protegidas com as melhores ferramentas do mercado.
-
-##### Confira as empresas que confiam em nossas soluções
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## Explore o Embedded Finance com a Dock
-
-Transforme sua empresa em uma líder no mercado financeiro digital, com uma experiência revolucionária para seus clientes.
-
-
-
-
-
-### Por que escolher a Dock?
-
-Nossa expertise e tecnologia permitem que sua empresa **promova inclusão financeira**, transformando clientes em participantes ativos e empoderando a economia digital. Estamos prontos para ajudar a **transformar seu negócio e causar um impacto positivo**.
-
-
-
-
-
-### O que é Embedded Finance?
-
-Imagine sua empresa oferecendo não só seus produtos habituais, mas também **serviços financeiros integrados**. Sua plataforma vira uma estação financeira, oferecendo desde pagamentos até empréstimos, **tudo dentro do ambiente digital**.
-
-[SAIBA MAIS](https://conteudo.dock.tech/embedded-finance "Clique e saiba mais")
-
-[SAIBA MAIS](https://conteudo.dock.tech/embedded-finance-en "Clique e saiba mais")
-
-[SAIBA MAIS](https://conteudo.dock.tech/embedded-finance-es "Clique e saiba mais")
-
-
-
-
-
-### Como a Dock impulsiona essa transformação?
-
-A Dock lidera serviços financeiros, fornecendo a **infraestrutura para que empresas expandam seus negócios**. Com nossa plataforma integrada e white label, ajudamos a lançar soluções financeiras personalizadas, com integração fluida e implantação ágil, unindo **inovação e eficiência**.
-
-## Conteúdos e eventos para ir além
-
-Conheça nossos conteúdos exclusivos e eventos que vão desbloquear ainda mais seu potencial de negócios.
-
-## Content and events to go further
-
-Discover our exclusive content and events that will unlock even more business potential.
-
-## Contenidos y eventos para ir más allá
-
-Conozca nuestros contenidos exclusivos y eventos que liberarán aún más su potencial de negocios.
-
-[
-
-
-
-](https://dock.tech/fluid/blog/cards-and-credit/dados-alternativos/ "Dados alternativos: como novas fontes de informação estão transformando o sistema financeiro e a análise de crédito")
-
-[
-
-Cards & Credit
-
-## Dados alternativos: como novas fontes de informação estão transformando o sistema financeiro e a análise de crédito
-
-](https://dock.tech/fluid/blog/cards-and-credit/dados-alternativos/ "Dados alternativos: como novas fontes de informação estão transformando o sistema financeiro e a análise de crédito")[SAIBA MAIS](https://dock.tech/fluid/blog/cards-and-credit/dados-alternativos/)
-
-[
-
-
-
-](https://dock.tech/fluid/blog/financeiro/fintechs-no-mexico/ "Fintechs no México: tendências, oportunidades e desafios de um dos cenários mais dinâmicos da América Latina")
-
-[
-
-Universo Financeiro
-
-## Fintechs no México: tendências, oportunidades e desafios de um dos cenários mais dinâmicos da América Latina
-
-](https://dock.tech/fluid/blog/financeiro/fintechs-no-mexico/ "Fintechs no México: tendências, oportunidades e desafios de um dos cenários mais dinâmicos da América Latina")[SAIBA MAIS](https://dock.tech/fluid/blog/financeiro/fintechs-no-mexico/)
-
-[
-
-
-
-](https://dock.tech/fluid/blog/banking/multibancarizacao/ "Como se destacar no setor de serviços financeiros em um contexto de multibancarização")
-
-[
-
-Banking
-
-## Como se destacar no setor de serviços financeiros em um contexto de multibancarização
-
-](https://dock.tech/fluid/blog/banking/multibancarizacao/ "Como se destacar no setor de serviços financeiros em um contexto de multibancarização")[SAIBA MAIS](https://dock.tech/fluid/blog/banking/multibancarizacao/)
-
-[
-
-
-
-](https://dock.tech/fluid/blog/cards-and-credit/processamento-de-cartoes/ "Processamento de cartões e meios de pagamento: quais as tendências e como oferecer a melhor experiência aos clientes")
-
-[
-
-Cards & Credit
-
-## Processamento de cartões e meios de pagamento: quais as tendências e como oferecer a melhor experiência aos clientes
-
-
-...27460 bytes truncated...
-
-The tool call succeeded but the output was truncated. Full output saved to: /home/alex/.local/share/opencode/tool-output/tool_d0c7326c6001XGAhVX6gf2xLCV
-Use the Task tool to have explore agent process this file with Grep and Read (with offset/limit). Do NOT read the full file yourself - delegate to save context.
-```
-
----
-
-## Assistant (Plan · gpt-5.4 · 40.8s)
-
-_Thinking:_
-
-**Summarizing financial platforms**
-
-I need to make it clear that the idea isn't just imaginary; it's the bundling that's unique. I might reference specific session files for context, but probably won’t need detailed paths or line numbers since the final answer should be self-contained. The user wishes to know about companies that exist, so I’ll mention that forms of financial access do exist in pieces, but the combinations are less common. I could categorize them, including Earned wage access with names like DailyPay and Branch, along with commission payout platforms like PayQuicker and Hyperwallet.
-
-_Thinking:_
-
-**Explaining PayQuicker**
-
-I need to highlight that PayQuicker specializes in quickly paying distributor commissions using branded cards and a user-friendly portal. There's a curated quote indicating that they pay out commissions within three hours of a sale. This quick turnaround emphasizes their efficiency in supporting distributors. It's essential to convey how their system works and the benefits it brings to users aiming for rapid commission access.
-
-_Thinking:_
-
-**Exploring commission infrastructure**
-
-I want to clarify that there are three types of companies: EWA, commission software, and embedded finance infrastructure. There's a notable gap in the "Brazil-first instant commission infrastructure" that combines payment collection, commission splitting, and other components. I should check if companies like DailyPay or Branch handle commission-based sales, but it seems they focus on general workforce payments. PayQuicker mentions direct selling payouts and commissions, while CaptivateIQ offers analytics. Combining these could create a solid solution. Caju shows a model in Brazil, but it leans more toward HR benefits than commission infrastructure.
-
-_Thinking:_
-
-**Considering structure for response**
-
-I might need to address that I’m not aware of a Swiss equivalent to this model, while Brazil seems to have a stronger presence. However, since the user only asks about existence, I may not need to go into much detail. It could be helpful to present my answer in bullet points for clarity. I should stick to a straightforward format, perhaps with a header like **Short Answer**, and keep everything concise and to the point.
-
-_Thinking:_
-
-**Evaluating payment solutions**
-
-I'm looking into commission and reward payouts, focusing on wallet-like portals and companies like PayQuicker, which offers instant payouts. There are others like CaptivateIQ for commission calculation and analytics, and Caju in Brazil, which facilitates payments through cards and Pix. I’ve noticed that there isn’t a clear category leader for a combined product that includes payment processing, instant commission splits, and analytics. So, the model is viable, but the specific bundling isn’t overly crowded.
-
-_Thinking:_
-
-**Gathering evidence for payment solutions**
-
-I’ll mention some key evidence: DailyPay offers on-demand pay and a prepaid card while partnering with banks, but they aren't a bank themselves. Then there's Branch, which provides earned wage access along with bank accounts and cards. PayQuicker claims commission payouts within three hours of sale, which is quite efficient. Caju, authorized by the Brazilian Central Bank, is a great example of a partner model. Notably, tying payments to merchant rails for employees to access funds immediately after customer payment seems unique. I could create a competitor map next to highlight differentiators.
-
-_Thinking:_
-
-**Reviewing payment solutions**
-
-I’m checking out several payment platforms. DailyPay offers on-demand pay and a prepaid card, allowing employees access to their full balance. Branch provides fast access to earnings through a bank account and a Mastercard debit card but isn’t a bank. PayQuicker enables direct selling payouts, showcasing a case where commissions are paid within three hours post-sale. CaptivateIQ automates commission calculations with real-time analytics. Caju is an authorized payment institution in Brazil, while Dock functions as a regulated participant in Pix. I might also mention Hyperwallet for global commission payouts, even if it's not limited to employment.
-
-_Thinking:_
-
-**Clarifying company structures**
-
-I need to note that no single company encompasses all aspects because employer payroll, merchant acquiring, wallet, and direct-sales commission payouts are heavily regulated and usually separate. That's a good point! Let's create a final concise structure.
-
-I can mention that companies like this exist in pieces. Closest real examples include DailyPay and Branch for earned wage access and early pay, along with PayQuicker for commission payouts in direct-selling businesses, using branded cards and portals.
-
-_Thinking:_
-
-**Exploring commission models**
-
-I found a customer quote mentioning that commissions can be paid within hours of a sale. For large-scale commission and reward payouts, there's Hyperwallet. Meanwhile, CaptivateIQ offers a commission engine with real-time visibility and analytics. In Brazil, companies like Caju and Dock show that the wallet, card, PIX, and regulatory infrastructure exists. However, I don’t see a single company combining all these features in a Brazil-first product.
-
-The model is viable, but the specific bundle isn’t really common. It’s best framed as a combination of earned wage access, commission infrastructure, and embedded finance.
-
-**Yes**
-- A company like this does exist in pieces, and a few companies get pretty close.
-- Closest matches I found:
- - `DailyPay` / `Branch`: earned wage access, faster worker payouts, cards, partner-bank model
- - `PayQuicker`: very close on commission payouts; it serves direct-selling businesses, supports branded cards/portals, and explicitly talks about fast commission payouts
- - `Hyperwallet`: large-scale commission/reward payout infrastructure
- - `CaptivateIQ`: commission calculation, visibility, forecasting, and analytics
- - In Brazil, `Caju` and `Dock` show that the `wallet + card + Pix + regulated partner/infrastructure` side is very real
-
-- What seems less common is one company combining all of this into one product:
- - collect the customer payment
- - split employer/employee balances instantly
- - let employees cash out via `PIX` or spend via card
- - optionally offer advance/EWA features
- - give employers commission analytics
-
-- So the best answer is: `yes, the model is real`, but `your exact bundle is not obviously saturated`.
-
-- The most interesting gap looks like: `earned wage access + commission engine + Brazil-native embedded finance`.
-
-If you want, I can next turn this into:
-1. a competitor map
-2. your likely differentiation vs these companies
-3. a Brazil-first go-to-market view
-
----
-
-## User
-
-do that
-
----
-
-## Assistant (Plan · gpt-5.4 · 32.6s)
-
-_Thinking:_
-
-**Planning Next Steps**
-
-I need to respond to the user's request to "do that," which likely refers to the previous options: competitor mapping, differentiation, and a Brazil-first go-to-market strategy. Since "do that" is a bit vague, I'll need to clarify whether they want all three or just one. The plan mode is active, so I should construct a well-researched plan. I can use available tools to gather the necessary information and present this plan effectively.
-
-_Thinking:_
-
-**Evaluating Compression Options**
-
-I might consider compressing the previous message range since the context isn’t crucial, but only if it’s closed and stale. I've already read the initial user question, fetched websites, and responded. Now, I can inspect the conversation IDs and decide which ranges to compress. It seems I might be looking at compressing from m0001 to m0004, although m0004 is blank. I’ll need to be careful with this process as we continue to gather more information.
-
-_Thinking:_
-
-**Considering User Intent and Compression**
-
-I need to preserve the user's intent while evaluating the message ranges. There was an initial question and an answer, and I could possibly compress from m0001 to m0004, including the user's request. However, m0001 is from the read output, not the user's initial message. It seems the IDs for the user's original message might not be visible before that. While I can compress those outputs, I still need to consider if the raw context is useful for clarity.
-
-**Tool: compress**
-
-**Input:**
-```json
-{
- "topic": "Startup Idea Research",
- "content": {
- "startId": "m0001",
- "endId": "m0004",
- "summary": "The user asked whether the company described in `session-ses_2fe5.md` exists. The file was read in full. It documented a startup concept discussed previously: a Brazil- or Switzerland-first fintech/payment platform that would receive customer payments for employers, calculate commissions in real time, credit employer and employee balances, let employees access earned commissions immediately via wallet/card/instant transfer, potentially offer employer-backed advances or earned wage access, and provide employer analytics on sales and commissions. The earlier discussion in the file concluded that the strongest wedge was Brazil-first instant commission access using `PIX`, with partner-bank or licensed financial institution infrastructure rather than direct custody. The memo also proposed later phases including stored balance, cards, float economics, employer analytics, and eventually risk-based credit.\n\nTo answer the existence question, several public company sites were fetched and inspected:\n- `DailyPay`: markets on-demand pay / earned wage access, employee cards, and partner-bank structure; strongest evidence that the earned-wage-access + card + employer integration model exists at scale.\n- `Branch`: workforce payments, earned wage access, app/card, embedded finance, sponsor banks; shows the fast-pay + card + employer/payroll integration model exists.\n- `CaptivateIQ`: commission automation, incentive compensation management, real-time visibility, planning, forecasting, and analytics; strong evidence that the commission-calculation / analytics piece exists as a standalone category.\n- `Caju` (Brazil): benefits/expense/payment platform, Brazilian payment institution, card issuance, and employee financial products; evidence that Brazil has real embedded-finance and employee-wallet/card infrastructure.\n- `Hyperwallet`: global payout infrastructure for commissions/rewards/contractors; validates payout orchestration and commission disbursement infrastructure.\n- `PayQuicker`: especially close on commission payouts; explicitly markets instant/real-time payouts, earned wage access, branded debit cards, and direct-selling commission payout use cases.\n- `Dock`: Brazilian financial infrastructure provider for digital accounts, `Pix`, cards, acquiring, and white-label financial services; evidence that the required banking/payment rails are available in Brazil. `Xerpay` could not be fetched due to connectivity.\n\nFrom those sources, the conclusion delivered to the user was:\n- Yes, companies like this exist in pieces, and a few get quite close.\n- The closest analogs are `DailyPay` / `Branch` for earned wage access and faster worker payouts, `PayQuicker` for commission payouts with cards/portals, `Hyperwallet` for payout infrastructure, `CaptivateIQ` for commission calculation and analytics, and Brazilian players such as `Caju` and infrastructure providers like `Dock` for the wallet/card/`Pix`/regulated-partner side.\n- What appears less common is a single company combining all elements into one product: customer payment collection, instant employer/employee split ledger, `PIX` or card access to balances, optional EWA/advances, and employer analytics.\n- The identified gap/opportunity was described as `earned wage access + commission engine + Brazil-native embedded finance`.\n\nThe assistant then offered three possible next deliverables: `1.` a competitor map, `2.` likely differentiation versus these companies, and `3.` a Brazil-first go-to-market view. The user replied: `do that`, which should be interpreted as asking for those follow-up analyses."
- }
-}
-```
-
-**Output:**
-```
-Compressed 4 messages into [Compressed conversation section].
-```
-
----
-
-## User
-
-▣ DCP | ~75.9K tokens saved total
-
-│⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿█████████████████│
-▣ Compression #1 (~75.9K tokens removed, 93% reduction)
-→ Topic: Startup Idea Research
-→ Items: 4 messages and 8 tools compressed
-
----
-
-## Assistant (Plan · gpt-5.4 · 104.1s)
-
-_Thinking:_
-
-**Planning and Analysis**
-
-I see that the user's request "do that" refers to developing a competitor map and differentiation strategy for a Brazil-first go-to-market approach. Right now, we're in plan mode, which is read-only, so I can't make any changes, but I can still search and explore ideas to create a well-formed plan. Since the user likely wants direct analyses from the previous conversation, I won't execute any code changes but could consider using webfetch to enhance my understanding, depending on the existing information I already have.
-
-_Thinking:_
-
-**Considering User Analyses**
-
-I realize that in plan mode, I still need to present a well-researched plan. The user requested analyses, which I might be able to provide directly from my existing knowledge. The current responsibility is to think, read, and search to construct a solid plan. The user asked "do that," indicating they likely expect deliverables. I can deliver a concise competitor map, differentiation, and go-to-market strategy framed as a planning memo, without changing the system. I’m contemplating whether to use webfetch to validate company details, but it might not be necessary given the context I already have.
-
-_Thinking:_
-
-**Evaluating Research Options**
-
-I’m considering whether to use webfetch to gather more specific details, but right now, I can provide a high-level competitor map and go-to-market strategy based on the available information. I could use a task to look into Brazil's regulatory and payment specifics, but that might be unnecessary. The user asked me to "do that," which suggests I should proceed without needing extra clarification, even though plan mode encourages asking questions. I need to think about context management; compressing information further might not be essential after a lengthy analysis.
-
-_Thinking:_
-
-**Evaluating company examples**
-
-I’m considering how to balance general knowledge with specific companies I've researched. While the instructions don't forbid general knowledge, sticking to well-known companies could enhance reliability. For instance, I can mention Fast worker payout solutions like DailyPay and Branch, along with commission payout infrastructures like PayQuicker and Hyperwallet. In Brazil, I might focus on Dock while mentioning others as general knowledge, and highlight integrations with ERP systems like Salesforce and HubSpot for a comprehensive approach.
-
-_Thinking:_
-
-**Identifying market segments in Brazil**
-
-I'm exploring merchant categories in Brazil that have commission-heavy teams, like field sales, retail chains, beauty clinics, auto dealers, telecom, and real estate. I need to pinpoint the best initial target market. Based on my startup concept focusing on Brazil, it seems that multi-location retail/service SMBs would be the best segment to start with. These businesses often have variable pay and high-frequency closers who would appreciate instant commission access, especially since employers face challenges with manual calculations.
-
-_Thinking:_
-
-**Evaluating target segments**
-
-I'm considering ideal initial segments for business focus, like telecom dealers, insurance agencies, and real estate brokerages. I want a group that has high commissions that can be paid frequently, ideally digitized payment events for quick access by employees.
-
-It's important that small to medium businesses struggle with commission reconciliation and employee turnover. I'll lean towards sectors where refunds and fraud can be managed, with faster sales cycles. A potential beachhead might be aesthetic clinics due to high-ticket sales, but I'll have to consider their cancellation issues carefully.
-
-_Thinking:_
-
-**Assessing service sectors for commissions**
-
-I'm considering different sectors for commission-based models. Beauty salons and barbershops already utilize chair rentals and commission, but their ticket sizes are lower, and competition might not be tech-savvy. Real estate offers big commissions but involves long settlement cycles and complex regulations.
-
-Insurance agencies pay commissions later, which complicates things. It seems like service SMBs, especially in beauty, wellness, fitness, or e-commerce, could be promising. The goal is to enable employers to collect payments directly, allowing for easy commission splits, so I'm leaning toward straightforward service businesses as an initial focus.
-
-_Thinking:_
-
-**Identifying a beachhead for services**
-
-I’m considering starting with service SMBs and franchise chains in Brazil where commissions are linked to transaction events, like clinics, beauty businesses, telecom retail, and education sales. The user wants a specific competitor map, differentiation, and go-to-market strategies, so I think beauty and aesthetics networks could be a solid choice.
-
-This sector has high commission intensity, turnover, and frequent digital payments. Managers typically dislike manual commission splits, and workers usually seek quicker access to earnings, which makes this market promising. However, I still need to confirm how payroll is managed since many businesses might be informal or rely on contractors—this could present both opportunities and challenges.
-
-_Thinking:_
-
-**Exploring payment strategies**
-
-Sales teams in B2B face challenges with customer payments, as invoices often settle later. A direct payment event is essential. So, "consumer services with same-day customer payments" seems promising. I might also consider direct-selling or insurance models with large distributed commissions. PayQuicker is relevant but may not be fully utilized in Brazil. Perhaps the best approach is a combination of merchant acquiring and a commission engine for franchises/SMBs. I can map competitors in a structured table for further analysis.
-
-_Thinking:_
-
-**Ranking payment solutions**
-
-I'm thinking about how to rank payment solutions based on their closeness to the ideal model. Closest options include PayQuicker for commission payouts, Branch for EWA, DailyPay for EWA/card, Hyperwallet for payout infrastructure, CaptivateIQ for commission analytics, Caju for employee finance in Brazil, and Dock for infrastructure in Brazil. I'll conclude there’s no clear all-in-one leader in this area. A matrix showing capabilities sounds useful, but maybe a concise bullet list will work better for clarity.
-
-_Thinking:_
-
-**Creating a mini scorecard**
-
-I'm considering a mini scorecard for different payment solutions. For instance, PayQuicker does well with payouts and direct-selling commissions but lacks in merchant payment collection and Brazil-native features. DailyPay offers EWA and worker cards but isn’t strong on commission engines. Branch provides wallet/card and payouts but has gaps in commission logic. Hyperwallet focuses on payout infrastructure but struggles with employer user experience. CaptivateIQ excels at commission calculations but has limitations in fund movement. I'll also include Caju and Dock as enablers in Brazil, not direct competitors.
-
-_Thinking:_
-
-**Identifying initial competition avoidance**
-
-I need to clarify where not to compete at first. I should avoid starting with general payroll/EWA for salaried employees or developing my own card program right away; I should first focus on PIX payouts. Also, no broad enterprise incentive planning, since that’s CaptivateIQ's area. My primary target should be Brazilian businesses with 50-500 employees, particularly those with commission-based frontline workers. I’m considering verticals like beauty clinics and telecom retail—let's analyze which might be a better fit.
-
-_Thinking:_
-
-**Defining service business strategies**
-
-I can categorize multi-unit service businesses with examples like beauty, dental, fitness, and education. It looks like the user wants more than just options, perhaps a perspective. My default focus is these consumer services, rather than general payroll or pure enterprise sales. I could articulate go-to-market steps, like developing a commission rules engine, an employer dashboard, and a worker wallet with cash-out options, along with a pricing structure involving SaaS fees and transaction charges.
-
-_Thinking:_
-
-**Exploring go-to-market strategies**
-
-I could share various channels, including direct founder-led sales to design partners and partnerships with payment processors, POS systems, and vertical SaaS. Messaging for employers should focus on reducing manual reconciliation, while for workers, it’s about receiving commissions quickly through PIX. Regulatory considerations involve partnering with licensed institutions and avoiding custody where possible. Success metrics to track include activation rates and employer retention. Plus, I could discuss expansion by adding features like card payments, stored balances, and benchmarking. Brazil might be a strategic priority due to the strong use of PIX and the expectation for instant money movement.
-
-_Thinking:_
-
-**Assessing regulatory considerations**
-
-I could mention that managing regulatory complexity is easier with a partner model. There might be potential questions around this. The plan suggests asking the user clarifying questions about trade-offs, although it may not be necessary. At the end, I could offer to turn this into investor positioning or a product roadmap. Since I'm not diving into implementation, suggestions should suffice. I need to decide whether to use tools for deeper research on Brazil's EWA regulatory nuances or PIX adoption, but the prior research might already be sufficient.
-
-_Thinking:_
-
-**Planning wage access analysis**
-
-I'm looking into Brazil's earned wage access regulation. The user didn't specifically request a deep regulatory dive, and I don’t want to overcomplicate things. Maybe using webfetch for a recent article isn't necessary right now, but I should keep it in mind. I want to create a simple, structured analysis of competitors and approach it as a direct deliverable, possibly with three sections and bullet points for clarity. Keeping it clear and focused is key!
-
-_Thinking:_
-
-**Creating a competitor map**
-
-The user wants a competitor map, and since I can't use tables here, I think a matrix layout might work better. I can start with a summary line like, "The market is crowded in slices, but there’s no clear Brazil-native all-in-one player." The map will highlight strong point solutions and weak full-stack overlaps.
-
-I could categorize competitors into four lanes: Worker money access (like DailyPay), commission intelligence (CaptivateIQ), payout rails (PayQuicker), and Brazil embedded finance (Caju, Dock). That should give a clear overview!
-
-_Thinking:_
-
-**Differentiating competitors**
-
-I think I should mention the closest threats, like PayQuicker teaming up with a local Brazilian BaaS partner or Caju with a commission engine. This fits into the differentiation section nicely.
-
-For differentiation, I can highlight:
-
-- Instead of "EWA for everyone," focus on "commission access for frontline sales teams."
-- Rather than "advance against payroll," emphasize "release money already earned from transaction ledger."
-- Swap "US-style card-first" for "Brazil-first PIX-first."
-- Change "back-office comp planning" to "payment-to-payout loop."
-- Lastly, replace "bank first" with "software distribution with regulated partner underneath."
-
-_Thinking:_
-
-**Considering competitive strategies**
-
-I could mention strategies for outflanking incumbents. For instance, `CaptivateIQ` targets enterprises while selling to downmarket or mid-market with instant payout features. `DailyPay` and `Branch` are more generic and focus on variable-pay teams with ROI from retention. `Caju` emphasizes benefits-first approaches, while `PayQuicker` offers global payout rails and local Brazil integrations. I might want to clarify differentiation from each competitor by providing specific advantages, like focusing on transaction-level commission earnings rather than payroll accesses.
-
-_Thinking:_
-
-**Considering next steps**
-
-I’m thinking that my natural next steps could be offering a 1-page investment memo, a 12-month product roadmap, and a pilot target list. That makes sense! I should probably include numeric options as it adds clarity. It might also be wise to mention some assumptions or caveats to give a more rounded view. That way, everything can be laid out logically and transparently for the user to understand.
-
-_Thinking:_
-
-**Clarifying user preferences**
-
-I’m considering whether to use the question tool to ask the user if they want an investor-facing or product-facing approach. However, the instructions say to default to doing the work without asking. So, I think I’ll just move forward. It may be good to mention that I can create a crisp positioning statement if they want. I'll go ahead and create a final answer with three clear headers to organize the information!
-
-_Thinking:_
-
-**Finalizing market analysis**
-
-It looks like the market map highlights a gap: many companies handle just one layer of the stack but don’t manage the entire process from customer payment to commission calculation to instant worker access in Brazil.
-
-In the competitor map, I see strengths and weaknesses for each player, like DailyPay and Branch excelling in earned wage access but lacking in commission logic. The open space really lies in combining a commission engine with instant payout and Brazil-native features. I’ll aim to position as "real-time commission access," differentiating from the generic EWA!
-
-The market map points to a clear gap: most companies own one layer of the stack, but not the full loop from customer payment to commission calculation to instant worker access in Brazil.
-
-**Competitor Map**
-- `DailyPay`, `Branch`: strong on earned wage access, worker app/card, and employer integrations; weak on commission logic and customer-payment-linked split ledgers.
-- `PayQuicker`, `Hyperwallet`: strong on payouts and disbursement infrastructure; weak on employer-side commission automation and Brazil-native positioning.
-- `CaptivateIQ`: strong on commission calculation, visibility, forecasting, and analytics; weak on money movement and employee cash-out.
-- `Caju`: strong on Brazil employee wallet/card experience; weak on being the system of record for commissions.
-- `Dock`: not a direct competitor; it is the kind of Brazil infrastructure layer you would likely build on top of for `Pix`, accounts, and cards.
-- The open space is the intersection: `commission engine + instant payout + Brazil-native rails + employer controls`.
-
-**Likely Differentiation**
-- vs `DailyPay` / `Branch`: position as `real-time commission access`, not generic EWA; earnings appear from transaction events, not payroll files.
-- vs `CaptivateIQ`: position as `sale-to-spend infrastructure`, not just incentive planning; you own the payout loop, not only the calculation layer.
-- vs `PayQuicker` / `Hyperwallet`: position as an employer operating system for commission-heavy teams, not just payout rails.
-- vs `Caju`: position as revenue-linked compensation infrastructure, not benefits or general employee finance.
-- The strongest wedge is `cash-flow-neutral instant commissions`: employer collects money, your system allocates earned amounts, workers withdraw via `Pix`, and lending stays out of v1.
-- What to avoid early: broad payroll, salary EWA for everyone, enterprise sales-comp planning, or balance-sheet credit.
-
-**Brazil-First GTM**
-- Start with commission-heavy Brazilian SMB and mid-market operators where payments are digital and earnings are attributable at transaction time: franchise retail, beauty/aesthetics, dental or elective health clinics, fitness, and education/course sales.
-- Sell to owners, finance/ops leads, and sales managers with a simple pitch: less manual commission work, better retention, faster payouts, and cleaner reconciliation.
-- Launch v1 with four core pieces: payment-linked commission rules, employer dashboard, worker balance with `pending` and `available` states, and instant `Pix` cash-out.
-- Use a partner-bank or licensed payment-institution model first; handle refunds and chargebacks with reserves and clawback rules instead of promising unconditional instant access.
-- Distribute through 3 channels: direct design-partner sales, vertical SaaS/POS/payment partners, and franchise groups or payroll/accounting referrals.
-- Price as software plus movement: platform fee, per active earner, and/or payout/processed-volume fee tied to employer ROI rather than consumer lending.
-
-My default thesis:
-`Don't build another EWA app. Build the Brazil-native commission ledger that turns every sale into an instantly accessible balance.`
-
-If you want, I can turn this into:
-1. a 1-page investor-style market memo
-2. sharper positioning and landing-page copy
-3. a phased 12-month product roadmap
-
----
-
-## User
-
-Yes do that, but also, create a document which contains the core parts of the idea we've discussed and a document that is focused specially on the Brazilian market
-
----
-
-## Assistant (Plan · gpt-5.4 · 11.5s)
-
-_Thinking:_
-
-**Exploring task management limitations**
-
-It looks like the tool manages a structured task list, but it’s in a read-only phase, so no system changes are allowed. While "Todowrite" is not a file change, it seems a bit unnecessary. I might inspect the repository for documentation locations, like session-ses_2fe5.md, and consider using glob/read to check the structure. If needed, I can ask about preferred formats or locations after checking the repo. Let’s prioritize non-blocked tasks before making any inquiries.
-
-_Thinking:_
-
-**Investigating directory structure**
-
-I think using glob or reading the directory could help me check if there’s a docs/ or notes/ folder since I’m limited to read operations. It might be a good idea to compress earlier messages after I make a plan, even though we have a short context right now. Looking at the range m0005-m0009 isn’t necessary at this moment since it’s still active. I could also run glob and search for markdown files while inspecting the root directory.
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll
-directory
-
-.git/
-session-ses_2fe5.md
-
-(2 entries)
-
-```
-
-**Tool: glob**
-
-**Input:**
-```json
-{
- "path": "/home/alex/projects/payroll",
- "pattern": "**/*.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/session-ses_2fe5.md
-```
-
-**Tool: glob**
-
-**Input:**
-```json
-{
- "path": "/home/alex/projects/payroll",
- "pattern": "**/docs/**"
-}
-```
-
-**Output:**
-```
-No files found
-```
-
----
-
-## Assistant (Plan · gpt-5.4 · 4.4s)
-
-_Thinking:_
-
-
-
-**Tool: read**
-
-**Input:**
-```json
-{
- "filePath": "/home/alex/projects/payroll/session-ses_2fe5.md"
-}
-```
-
-**Output:**
-```
-/home/alex/projects/payroll/session-ses_2fe5.md
-file
-1: # Payment processing with early commission payouts and bank partnerships
-2:
-3: **Session ID:** ses_2fe58810cffeU8IzEZHZRCZF25
-4: **Created:** 3/18/2026, 3:54:07 PM
-5: **Updated:** 3/18/2026, 4:18:46 PM
-6:
-7: ---
-8:
-9: ## User
-10:
-11: The core of the idea is: a company that process payments and pays out commissions to employees before sending the money to employers
-12: However there are some other parts of the idea that I'm still not sure how to put together, for example:
-13: 1) Partnering with banks so that they hold the money and manage that
-14: 2) What are the technologies we can use to process payments
-15:
-16: ---
-17:
-18: ## Assistant (Plan · gpt-5.4 · 24.6s)
-19:
-20: A cleaner way to frame the idea is:
-21:
-22: - A business receives customer payments.
-23: - Your platform calculates commissions owed to employees from those payments.
-24: - The funds are held with a regulated bank partner, not by you directly.
-25: - Your system instructs payouts to employees first, then sends the remaining balance to the employer.
-26:
-27: That gives you a clearer model: payment orchestration + commission ledger + regulated banking partner.
-28:
-29: What usually fits best
-30:
-31: - `You` are the software and workflow layer: calculate splits, track balances, trigger payouts, reporting.
-32: - `Bank partner` holds the money in safeguarded/FBO-style accounts and handles regulated money movement.
-33: - `Payment processor` collects the incoming payment.
-34: - `Payout rails` send money to employees and employers.
-35:
-36: How the bank partnership piece usually works
-37:
-38: - You generally do not want to custody funds yourself early on.
-39: - Instead, partner with a sponsor bank or Banking-as-a-Service provider.
-40: - The bank holds funds, manages compliance requirements around accounts/movement, and settles transactions.
-41: - Your platform keeps a ledger of who is owed what and sends payment instructions through APIs.
-42:
-43: Typical model
-44:
-45: - Customer pays `1000`.
-46: - Your rules engine says employee commission = `200`.
-47: - Bank-held account receives `1000`.
-48: - Platform ledger records:
-49: - employee payable `200`
-50: - employer payable `800`
-51: - Payout engine sends `200` to employee, `800` to employer.
-52:
-53: Key legal/regulatory point
-54:
-55: - This starts to look like `payments + payroll + earned commissions`, so regulation matters a lot.
-56: - Depending on geography, you may touch:
-57: - money transmission
-58: - payroll/wage laws
-59: - KYC/KYB/AML
-60: - card/network rules
-61: - tax reporting
-62: - So the safest early approach is usually: `bank + licensed payment partners + your software layer`, rather than becoming the regulated entity yourself.
-63:
-64: Tech stack options
-65:
-66: - **Payment acceptance**
-67: - `Stripe`, `Adyen`, `Checkout.com`
-68: - Good for cards, basic ACH, merchant onboarding
-69: - **Banking / money movement**
-70: - `Stripe Treasury`, `Modern Treasury`, `Moov`, `Increase`, `Dwolla`
-71: - Good for ACH, wires, RTP, virtual accounts, balance tracking
-72: - **Identity / compliance**
-73: - `Plaid` for bank linking
-74: - `Alloy`, `Persona`, `Sardine` for KYC/KYB/fraud
-75: - **Ledger / commissions engine**
-76: - Internal double-entry ledger
-77: - Or tools like `Modern Treasury Ledgers`, `Formance`, `TigerBeetle`
-78: - **Core app stack**
-79: - Backend: `Node.js/TypeScript`, `Python`, or `Go`
-80: - DB: `PostgreSQL`
-81: - Queue/workflows: `BullMQ`, `Temporal`, `SQS`
-82: - Audit/reporting: event log + immutable ledger tables
-83:
-84: A practical MVP shape
-85:
-86: - Employer onboarding
-87: - Employee onboarding
-88: - Payment collection
-89: - Rules engine for commission calculation
-90: - Internal ledger for split accounting
-91: - Manual or scheduled payouts
-92: - Dashboard for balances, payouts, disputes, reports
-93:
-94: Best first partnership strategy
-95:
-96: - Start with a provider that already has bank relationships and payout rails.
-97: - Don’t begin by negotiating directly with a large bank unless you already have scale.
-98: - A common sequence is:
-99: 1. use `Stripe/Adyen` for incoming payments
-100: 2. use `Modern Treasury/Moov/Increase` for payout orchestration
-101: 3. add direct bank relationships later if volume justifies it
-102:
-103: The hardest parts are usually not the code
-104:
-105: - commission rule complexity
-106: - timing of fund availability
-107: - reversals/chargebacks
-108: - compliance and licensing boundaries
-109: - disputes between employee and employer
-110: - tax and payroll treatment of commissions
-111:
-112: If you want, I can next help with one of these:
-113: 1. turn this into a one-paragraph startup description
-114: 2. design the full product/payment flow step by step
-115: 3. suggest a concrete MVP stack for building this in 3 months
-116:
-117: ---
-118:
-119: ## User
-120:
-121: Right, so what I am thinking is having accounts for the employers and employees and credit money to their accounts in our system when we receive the payments. We need to find a way to incentivise them to leave their money with us for as long as possible to earn interest off off the cash that we're holding. One way I was thinking of doing this is by having credit/debit cards for the users so that they could spend their money directly from their account, while still leaving the option for them to wire that money to their own bank account. I'm considering starting this company in either switzerland or brazil, given that I have people in both countries that I could leverage and bring into this startup. I don't know much about the swiss market, but I know that the brazilian market currently has some smaller banks that seem eager to find partnerships to gain market share, Sicredi for example. Also, in brazil we have PIX which makes wiring money fast and cheap, which could be a great selling point, something along the lines of being able to tell the sales staff that they can instantly have access to their commissions the moment the customer makes a payment.
-122:
-123: ---
-124:
-125: ## Assistant (Plan · gpt-5.4 · 34.2s)
-126:
-127: You’re moving from “commission payout software” toward a much bigger model: `stored balances + instant access + cards + bank transfers`. That can be powerful, but it changes the company a lot.
-128:
-129: The key strategic split
-130:
-131: - If you only calculate commissions and trigger payouts, you’re mainly a software/payments orchestration company.
-132: - If you hold balances in user accounts, let them keep funds, offer cards, and earn yield on float, you start to look like a fintech / neobank / regulated money business.
-133:
-134: That second version is much more valuable, but much harder.
-135:
-136: What I think is strongest in your idea
-137:
-138: - The best wedge is not “we hold your money.”
-139: - The best wedge is “salespeople get instant access to commissions the moment a sale clears.”
-140: - In Brazil, that pitch is especially strong because `PIX` makes instant movement normal and expected.
-141: - A card attached to the balance makes the money feel immediately usable, which is a real behavioral incentive not to cash out.
-142:
-143: Important caution on “earning interest off the cash”
-144:
-145: - This is attractive economically, but it is also where regulation gets much more serious.
-146: - You generally cannot just “hold client money and earn interest on it” however you want.
-147: - You need to be very clear on:
-148: - who legally holds the funds
-149: - whether funds are customer assets or your operating cash
-150: - whether yield/interest belongs to the customer, the bank, or your platform
-151: - whether your product becomes regulated as stored value, e-money, deposit-like activity, or money transmission
-152: - So the safer version is usually:
-153: - partner bank or licensed institution holds funds
-154: - your platform maintains the subledger and user experience
-155: - cards and transfers are issued through licensed partners
-156: - your economics come from interchange, SaaS, take rate on processing, float-sharing agreement if allowed, and treasury arrangements
-157:
-158: Your proposed product architecture
-159:
-160: - Employer account in your app
-161: - Employee account in your app
-162: - Incoming payment lands into safeguarded/partner-held funds
-163: - Your ledger allocates the split instantly
-164: - Employee sees commission balance immediately
-165: - Employee can:
-166: - spend with card
-167: - transfer out to bank
-168: - maybe keep balance for future spending
-169: - Employer receives remaining balance on schedule or instantly
-170:
-171: That is a coherent product.
-172:
-173: Why Brazil looks stronger than Switzerland for the first launch
-174:
-175: - `PIX` is a huge distribution advantage for instant payouts.
-176: - User behavior already accepts real-time transfers.
-177: - Smaller financial institutions may be more open to partnerships.
-178: - The pain point around delayed commission access feels easier to explain.
-179: - Switzerland is wealthy and credible, but likely harder as a first market unless you already have strong local regulatory and banking access.
-180:
-181: My default view: start in `Brazil`, not Switzerland, unless your Swiss network includes real bank/compliance operators.
-182:
-183: Why cards are smart
-184:
-185: - A card makes the balance useful without forcing bank withdrawal.
-186: - That increases retention of funds in the system.
-187: - It also creates interchange revenue.
-188: - It changes the product from “payout tool” to “financial home for commission earners.”
-189:
-190: But cards should probably be phase 2, not day 1.
-191:
-192: Recommended rollout
-193:
-194: 1. `Phase 1`: instant commission ledger + PIX payout
-195: - receive merchant payment
-196: - calculate split
-197: - show employee available commission immediately
-198: - let employee cash out instantly via PIX
-199: - let employer settle on schedule
-200:
-201: 2. `Phase 2`: stored balance
-202: - employee can keep balance in app
-203: - employer can hold operating balance for future payouts
-204: - basic wallet behavior
-205:
-206: 3. `Phase 3`: card issuance
-207: - prepaid/debit card tied to stored balance
-208: - spend directly from commission account
-209: - optional employer expense or draw features later
-210:
-211: 4. `Phase 4`: treasury economics
-212: - negotiated bank yield/float arrangements
-213: - maybe employer incentives for keeping balances
-214: - maybe employee rewards instead of explicit interest
-215:
-216: Better incentive framing
-217:
-218: Instead of saying “leave money with us so we earn interest,” design the product so users naturally keep balances because it is useful:
-219:
-220: - instant commission availability
-221: - free PIX transfers
-222: - card spend with cashback/rewards
-223: - early access to future commissions
-224: - bill pay / payroll-like convenience
-225: - employer bonuses for keeping payout reserves on platform
-226:
-227: That is commercially cleaner and safer to message.
-228:
-229: Core risks you should think through now
-230:
-231: - **Regulatory boundary**: are you software, payment institution, wallet, or something deposit-like?
-232: - **Fund timing**: when is money truly available vs still reversible?
-233: - **Chargebacks/refunds**: what happens if you already paid the employee?
-234: - **Labor law**: are instant commissions legally “earned wages,” “advances,” or something else?
-235: - **Partnership dependence**: your bank/program manager/card issuer can become a bottleneck.
-236: - **Unit economics**: instant payouts and card programs only work if fees, fraud, and support stay under control.
-237:
-238: My practical recommendation
-239:
-240: - Build the company narrative around `instant commission access infrastructure for employers and sales teams`.
-241: - Start with `Brazil`.
-242: - Use `PIX` as the hero feature.
-243: - Do not make “we profit from holding your cash” the public core story.
-244: - Structure the first version with a licensed financial partner holding funds.
-245: - Add cards only after the payout/ledger engine works reliably.
-246:
-247: A clean positioning statement
-248:
-249: - “We help companies collect payments and give sales teams instant access to earned commissions, with employer and employee balances managed through regulated financial partners.”
-250:
-251: If you want, I can next do one of these:
-252: 1. turn this into a proper startup thesis and business model
-253: 2. map the exact money flow and partner stack for a Brazil-first launch
-254: 3. compare Brazil vs Switzerland in a founder-style decision memo
-255:
-256: ---
-257:
-258: ## User
-259:
-260: One practice that is quite common place in Brazil, that this company could potentially reduce, but probably not eliminate is what they call "vales", which are essentailly advances on their paycheck. I think there's good potential in also making it a feature in the business, letting employees borrow against their paycheck for a small fee/interest.
-261:
-262: ---
-263:
-264: ## Assistant (Plan · gpt-5.4 · 19.7s)
-265:
-266: That can be a strong feature, but it splits into two very different products:
-267:
-268: - `Earned wage access` — employees withdraw commission/pay already earned but not yet settled.
-269: - `Consumer credit` — employees borrow against expected future paycheck/commission.
-270:
-271: Those look similar in the app, but operationally they are very different.
-272:
-273: My recommendation
-274:
-275: - Start with `earned commission access`, not lending.
-276: - Treat it as “access to already-earned money” whenever possible.
-277: - Only explore true advances/credit later, once you have repayment data and employer integrations.
-278:
-279: Why this matters
-280:
-281: - `Earned access` is easier to explain: “you already earned it, we just make it available sooner.”
-282: - `Lending` creates heavier risk around underwriting, defaults, collections, regulation, and reputation.
-283: - In Brazil, a product that feels like replacing `vales` is attractive, but you do not want to become just another salary-advance lender.
-284:
-285: Best product framing
-286:
-287: - Employee makes a sale.
-288: - Payment is received or sufficiently authorized.
-289: - Your engine calculates commission instantly.
-290: - A safe portion becomes `available now`.
-291: - Employee can:
-292: - withdraw via `PIX`
-293: - spend via card
-294: - keep balance in wallet
-295: - For amounts not yet fully settled, you can show:
-296: - `available now`
-297: - `pending settlement`
-298: - `future estimated commissions`
-299:
-300: That lets you reduce `vales` without promising money too early.
-301:
-302: Rollout path
-303:
-304: 1. `Phase 1: Early access to earned commissions`
-305: - no true loan
-306: - only release funds tied to clear sales/payment events
-307: - set conservative availability rules
-308:
-309: 2. `Phase 2: Employer-backed advances`
-310: - employer opts in
-311: - employer agrees payroll deduction / settlement logic
-312: - advance limits based on verified earnings history
-313:
-314: 3. `Phase 3: Risk-based credit`
-315: - only if economics and regulation make sense
-316: - requires underwriting, loss reserves, collections, disclosures
-317:
-318: Key design choice
-319:
-320: - Use `employer-backed advance` before `standalone consumer lending`.
-321: - If the employer contract helps recover advances from payroll/commissions, risk drops a lot.
-322: - That keeps the product closer to B2B2C infrastructure than pure retail credit.
-323:
-324: Big risks to solve
-325:
-326: - **Settlement risk**: what if customer payment reverses after employee got paid?
-327: - **Commission disputes**: what if employer later changes the commission amount?
-328: - **Legal classification**: earned wage access vs credit product
-329: - **Collections**: what happens if employee leaves the company?
-330: - **Abuse**: employees repeatedly pulling advances before reversals/refunds are known
-331:
-332: Practical guardrails
-333:
-334: - Only advance against `verified and rule-locked` commissions
-335: - Keep a reserve/holdback for refunds and chargebacks
-336: - Cap instant access to a percentage, not 100%, at first
-337: - Require employer integration and approval
-338: - Price it as a transparent convenience fee, not compounding debt
-339: - Avoid language that makes it sound like payday lending
-340:
-341: Strong positioning
-342:
-343: - “We help companies eliminate informal paycheck advances by giving employees controlled, instant access to earned commissions.”
-344:
-345: What I’d plan next
-346:
-347: - Define three balance states: `earned`, `available`, `settled`
-348: - Make `PIX instant cash-out` the core Brazil feature
-349: - Keep wallet/cards as retention tools
-350: - Defer true lending until you have data on repayment, reversals, and employer behavior
-351:
-352: If you want, I can next do one of these:
-353: 1. draft a Brazil-first product roadmap including this feature
-354: 2. map the risk rules for `earned access` vs `advance`
-355: 3. write a founder memo on why this should start as EWA, not lending
-356:
-357: ---
-358:
-359: ## User
-360:
-361: Another part that I think can be valuable to companies is the possibility of giving them information on the performance of sales staff through amount of commissions, projections, some other forms of telemetry, etc
-362:
-363: ---
-364:
-365: ## Assistant (Plan · claude-opus-4.6 · 28.4s)
-366:
-367: That's a natural extension and it gives the product a second value proposition beyond money movement: `sales intelligence powered by real transaction data`.
-368:
-369: Why this is strong
-370:
-371: - You already have the data because payments flow through your system.
-372: - Most commission tracking today lives in spreadsheets or disconnected CRMs.
-373: - Employers currently have to reconstruct sales performance from multiple sources.
-374: - Your platform sees the actual money, so your data is inherently more trustworthy than self-reported CRM entries.
-375:
-376: What you can offer
-377:
-378: **Real-time dashboards for employers**
-379:
-380: - Total commissions paid per employee, team, region, period
-381: - Revenue per salesperson
-382: - Average deal size and frequency
-383: - Commission cost as percentage of revenue
-384: - Top performers vs underperformers
-385: - Trends over time (weekly, monthly, quarterly)
-386:
-387: **Projections and forecasting**
-388:
-389: - Projected commission liability for the month based on current pace
-390: - Expected payout amounts before settlement
-391: - Seasonal patterns and trend analysis
-392: - Cash flow forecasting for the employer (how much they need in the system to cover upcoming payouts)
-393:
-394: **Employee-facing insights**
-395:
-396: - "You've earned X this month, Y this quarter"
-397: - Progress toward targets or tiers
-398: - Comparison to personal history
-399: - Estimated next payout
-400:
-401: **Alerts and anomalies**
-402:
-403: - Sudden drop in an employee's sales
-404: - Unusually high refund/chargeback rate for a salesperson
-405: - Commission costs trending above budget
-406: - Employees approaching advance limits
-407:
-408: **Operational telemetry**
-409:
-410: - Time from sale to commission availability
-411: - Payout speed and method distribution
-412: - Cash-out frequency per employee
-413: - Balance retention rates
-414:
-415: Why this matters strategically
-416:
-417: - Analytics transforms your product from `payment plumbing` into `business intelligence`.
-418: - It makes the employer the buyer, not just the payer.
-419: - It increases switching costs — once employers rely on your dashboards, leaving is harder.
-420: - It opens a path to premium/enterprise pricing tiers.
-421:
-422: Important nuance
-423:
-424: - The analytics should come from data you already collect through payment processing.
-425: - Do not try to become a full CRM or HR platform.
-426: - Stay focused on `money-linked sales performance`, not general employee management.
-427:
-428: How it fits in the product
-429:
-430: | Layer | What it does |
-431: |---|---|
-432: | Payment engine | Collect, split, settle |
-433: | Ledger / wallet | Track balances, enable instant access |
-434: | Cards / PIX | Make money usable |
-435: | Analytics | Make the data useful to employers |
-436:
-437: The analytics layer is essentially free to build incrementally because the underlying data already exists in your ledger. It's a reporting and visualization problem, not a data collection problem.
-438:
-439: Pricing angle
-440:
-441: - Basic analytics included in the platform fee
-442: - Advanced analytics (projections, anomaly detection, custom reports, API access) as a premium tier
-443: - That gives you a SaaS-like revenue stream alongside transaction-based revenue
-444:
-445: Recommended approach
-446:
-447: - Ship basic dashboards early — even simple charts increase perceived value significantly.
-448: - Add projections and alerts as you accumulate enough historical data.
-449: - Let employer feedback drive which analytics matter most.
-450: - Do not over-invest in analytics before the core payment/payout engine works.
-451:
-452: At this point, the full product vision is becoming clear:
-453:
-454: 1. **Payment collection** — employer receives customer payments through you
-455: 2. **Commission engine** — rules-based split calculation
-456: 3. **Instant access** — employees see and use earned commissions immediately
-457: 4. **Wallet + cards + PIX** — money stays in system, usable without withdrawal
-458: 5. **Earned wage access / advances** — reduce informal "vales"
-459: 6. **Sales analytics** — employer gets performance intelligence from real payment data
-460: 7. **Float economics** — platform earns from balances, interchange, fees
-461:
-462: That is a coherent, defensible fintech product.
-463:
-464: Do you want me to now pull all of this together into one of these:
-465: 1. A structured startup thesis / business model document
-466: 2. A phased product roadmap with priorities
-467: 3. A technical architecture plan for building the MVP
-468:
-469: ---
-470:
-471: ## User
-472:
-473: 1
-474:
-475: ---
-476:
-477: ## Assistant (Plan · claude-opus-4.6 · 59.7s)
-478:
-479:
-480:
-481: Here is the structured startup thesis and business model.
-482:
-483: ---
-484:
-485: # Startup Thesis: Instant Commission Infrastructure
-486:
-487: ## One-liner
-488:
-489: A B2B2C fintech platform that sits between employers and sales staff, processing customer payments, instantly calculating and distributing commissions, and providing financial accounts with cards and instant transfers — while earning from float, interchange, fees, and SaaS.
-490:
-491: ---
-492:
-493: ## Problem
-494:
-495: **For employers:**
-496: - Commission calculation is manual, error-prone, and delayed.
-497: - Payroll cycles create lag between a sale and the salesperson getting paid.
-498: - Informal advance practices ("vales") are unstructured, create accounting friction, and expose the company to risk.
-499: - Visibility into sales performance is fragmented across CRM, payroll, and spreadsheets.
-500:
-501: **For employees (sales staff):**
-502: - Commissions arrive days or weeks after the sale.
-503: - Accessing earned money early requires asking for informal advances.
-504: - No single place to see earnings, track performance, or manage commission income.
-505:
-506: ---
-507:
-508: ## Solution
-509:
-510: A platform that:
-511:
-512: 1. Receives customer payments on behalf of the employer.
-513: 2. Instantly calculates the commission split using employer-defined rules.
-514: 3. Credits the employee's account with earned commission in real time.
-515: 4. Lets employees spend (card), transfer (PIX), or hold their balance.
-516: 5. Settles the employer's share on their preferred schedule.
-517: 6. Provides both sides with analytics, projections, and reporting.
-518:
-519: ---
-520:
-521: ## How money flows
-522:
-523: ```
-524: Customer pays R$1,000
-525: │
-526: ▼
-527: ┌─────────────────────────┐
-528: │ Partner bank / FBO │ ← Regulated entity holds funds
-529: │ account receives funds │
-530: └─────────────────────────┘
-531: │
-532: ▼
-533: ┌─────────────────────────┐
-534: │ Platform ledger splits │
-535: │ Employee: R$200 │
-536: │ Employer: R$800 │
-537: │ Platform fee: deducted │
-538: └─────────────────────────┘
-539: │ │
-540: ▼ ▼
-541: Employee acct Employer acct
-542: (available now) (settles on schedule)
-543: │
-544: ├── PIX cash-out (instant)
-545: ├── Card spend (interchange)
-546: └── Hold balance (float)
-547: ```
-548:
-549: ---
-550:
-551: ## Revenue model
-552:
-553: | Stream | Description | Phase |
-554: |---|---|---|
-555: | **Transaction fee** | % or flat fee on each payment processed | 1 |
-556: | **PIX/transfer fee** | Small fee per cash-out (or free with limits) | 1 |
-557: | **Float income** | Interest/yield on balances held with bank partner | 2 |
-558: | **Card interchange** | Revenue share on card transactions | 3 |
-559: | **Advance fee** | Flat fee for early access to not-yet-settled commissions | 2 |
-560: | **SaaS tier** | Premium analytics, custom rules, API access, multi-entity | 2 |
-561:
-562: The strongest early revenue is likely `transaction fee + advance fee`. Float and interchange grow with balance retention and card adoption.
-563:
-564: ---
-565:
-566: ## Target market (Brazil first)
-567:
-568: **Initial segment:**
-569: - Small and mid-size companies with commission-based sales teams (5–200 salespeople).
-570: - Industries: retail, insurance, real estate, auto dealers, door-to-door sales, telecoms resellers.
-571:
-572: **Why Brazil:**
-573: - PIX makes instant transfers a baseline expectation.
-574: - "Vales" culture creates a clear pain point to solve.
-575: - Smaller banks (e.g., Sicredi, cooperatives) are actively seeking partnerships to grow.
-576: - Large underbanked/underserved workforce in commission-based roles.
-577: - Regulatory environment has a clear framework for payment institutions.
-578:
-579: **Why not Switzerland first:**
-580: - Harder to find flexible bank partners without existing scale.
-581: - Smaller addressable market for commission-heavy sales forces.
-582: - Higher regulatory and operational costs to start.
-583: - Consider Switzerland as a second market or for a different product angle (e.g., wealth/treasury for employers).
-584:
-585: ---
-586:
-587: ## Product roadmap
-588:
-589: ### Phase 1 — Core (months 1–4)
-590: - Employer onboarding and configuration
-591: - Employee onboarding (KYC via partner)
-592: - Payment collection (PIX, boleto, card via payment processor)
-593: - Commission rules engine (percentage, tiered, custom)
-594: - Internal double-entry ledger
-595: - Employee balance: `earned` / `pending` / `settled`
-596: - PIX instant cash-out for employees
-597: - Employer settlement on schedule
-598: - Basic employer dashboard (commissions paid, per-employee breakdown)
-599: - Basic employee dashboard (earnings, available balance, cash-out history)
-600:
-601: ### Phase 2 — Retention + advances (months 4–7)
-602: - Employee wallet with stored balance
-603: - Earned wage access: early access to earned-but-unsettled commissions
-604: - Employer-backed advance feature (payroll-deductible)
-605: - Reserve/holdback logic for refunds and chargebacks
-606: - Employer analytics: performance trends, projections, commission cost ratios
-607: - Employee insights: earnings pace, personal trends
-608: - Alerts: anomalies, budget thresholds, refund spikes
-609: - Premium SaaS tier for analytics
-610:
-611: ### Phase 3 — Cards + scale (months 7–12)
-612: - Prepaid/debit card issuance (via card program manager)
-613: - Card spend from commission balance
-614: - Interchange revenue
-615: - Float optimization with bank partner
-616: - Multi-entity / franchise support
-617: - API for employer system integrations (ERP, CRM, POS)
-618: - Employer cash flow forecasting
-619:
-620: ### Phase 4 — Expansion (12+ months)
-621: - Risk-based credit / true advances (if regulation allows and data supports)
-622: - Employee rewards / cashback programs
-623: - Second market entry (Switzerland or other LatAm)
-624: - Employer expense management features
-625: - White-label or embedded finance partnerships
-626:
-627: ---
-628:
-629: ## Key partnerships needed
-630:
-631: | Partner type | Role | Examples (Brazil) |
-632: |---|---|---|
-633: | **Sponsor bank / BaaS** | Hold funds, compliance, account infrastructure | Sicredi, QI Tech, Dock, Celcoin |
-634: | **Payment processor** | Accept PIX, boleto, cards | Pagar.me, Stripe BR, Adyen |
-635: | **Card issuer / program manager** | Issue prepaid/debit cards | Dock, Pomelo, Swap Financial |
-636: | **KYC/KYB provider** | Identity verification | idwall, BigDataCorp |
-637: | **Legal / regulatory counsel** | Payment institution licensing, labor law | Local fintech law firm |
-638:
-639: ---
-640:
-641: ## Regulatory considerations (Brazil)
-642:
-643: - **Payment institution license**: likely needed if holding client funds or issuing payment instruments. Can potentially operate under a bank partner's license initially.
-644: - **Central Bank oversight**: PIX participation rules, reporting obligations.
-645: - **Labor law**: commission classification, payroll deduction rules for advances, tax withholding obligations.
-646: - **Consumer protection (CDC)**: transparency on fees, right to information.
-647: - **LGPD**: data protection for employee financial data.
-648: - Early recommendation: operate under a licensed partner's umbrella, pursue your own license when volume justifies it.
-649:
-650: ---
-651:
-652: ## Core risks
-653:
-654: | Risk | Mitigation |
-655: |---|---|
-656: | Settlement reversal after payout | Holdback reserves, conservative availability windows |
-657: | Commission disputes | Employer-signed rules, audit trail, dispute workflow |
-658: | Employee default on advances | Employer-backed payroll deduction, conservative limits |
-659: | Bank partner dependency | Contractual protections, plan for multi-partner |
-660: | Regulatory classification | Legal counsel from day 1, operate under licensed partner |
-661: | Fraud / identity | KYC at onboarding, transaction monitoring |
-662: | Low balance retention | Card + UX incentives to keep funds in-platform |
-663:
-664: ---
-665:
-666: ## Unit economics sketch (per employer, per month)
-667:
-668: Assuming: 20 employees, R$500 avg commission, 80% cash-out rate
-669:
-670: | Item | Value |
-671: |---|---|
-672: | Total commissions processed | R$10,000 |
-673: | Transaction fee (2%) | R$200 |
-674: | Advance fees (10% of employees, R$5 each) | R$10 |
-675: | Float income (20% retained, ~1% monthly yield) | R$20 |
-676: | Interchange (Phase 3, est.) | R$15 |
-677: | **Monthly revenue per employer** | **~R$245** |
-678: | Target: 200 employers | **~R$49,000/mo** |
-679:
-680: These are rough and conservative. The real leverage comes from larger employers and higher retention rates.
-681:
-682: ---
-683:
-684: ## Competitive positioning
-685:
-686: - Not a payroll company. Not a bank. Not a CRM.
-687: - "Commission infrastructure" — the financial operating system between employer payments and sales team earnings.
-688: - Closest comparisons internationally: `Earned wage access` (DailyPay, Caju, Xerpay) crossed with `payment splitting` (Stripe Connect model) crossed with `sales performance analytics`.
-689: - Differentiation: you process the actual payment, so you have the most trustworthy data and the fastest path to commission availability.
-690:
-691: ---
-692:
-693: ## Founding team needs
-694:
-695: - **Product / business lead**: understands the employer sales pain, can sell to mid-market companies.
-696: - **Engineering lead**: can build ledger, payment integrations, real-time systems.
-697: - **Fintech / regulatory lead**: understands Brazilian payment institution rules, bank partnerships, compliance.
-698: - Ideally, at least one founder with direct relationships at potential bank partners.
-699:
-700: ---
-701:
-702: That covers the thesis, model, market, roadmap, risks, and economics. Want me to go deeper on any section, or move toward technical architecture or a specific partnership strategy?
-703:
-704: ---
-705:
-
-(End of file - total 705 lines)
-
-```
-
----
-
-## Assistant (Plan · gpt-5.4 · 85.4s)
-
-_Thinking:_
-
-**Planning document creation**
-
-I need to inspect the repo, focusing on the session file. It seems like I'll propose a plan for creating an investor-style memo and two documents. I wonder if there are existing structures I can reference since there's only one markdown file. The user wants me to create three deliverables: the investor memo, landing-page content, and a phased product roadmap along with a core idea doc and a Brazil-focused doc. Since I'm in plan mode, I can't create documents now, only prepare the structure.
-
-_Thinking:_
-
-**Clarifying document requirements**
-
-I think I need to ask a clarifying question since it’s unclear whether the user wants all five documents or some combined. I should analyze the context: the prior assistant provided a competitor map, differentiation, Brazil-first GTM, and offered three specific documents: an investor-style market memo, sharper positioning and landing-page copy, plus a phased 12-month roadmap. The user wants those, along with a core idea doc and a Brazil-focused document, so likely all five documents are needed. I’ll need a plan and maybe check the repo for where to place them.
-
-_Thinking:_
-
-**Planning documentation structure**
-
-I'm considering using `git status --short` just to see the current workspace state, though it might not be necessary since I'm still planning. I could check for a README or a docs directory, but all I have are session files for now. I think I should propose creating a `docs/` folder for documentation. However, I only need to consider if the user wants five separate documents or a combined one, which might not be essential. I can default to five markdown docs in the `docs/` folder.
-
-_Thinking:_
-
-**Defining audience and document needs**
-
-I'm considering whether I should ask about the target audience, but it seems like I can infer what the user wants based on previous discussions. It looks like they want startup planning documents, including potentially different styles like investor memos and landing-page copy. They also requested a Brazil-specific document. I might need to search for Brazil-specific insights to supplement our research. However, my focus is still on planning rather than execution, so I’ll concentrate on crafting a detailed yet concise plan.
-
-_Thinking:_
-
-**Gathering context and planning**
-
-I should probably gather any additional context from the existing session file to see what we have so far on Brazil. It might be useful to fetch web information about Brazilian regulations to enrich the plan, especially since the user wants a document focused on the Brazilian market. I could also check if `session-ses_2fe5.md` provides enough information. I’m thinking it might be excessive to gather too much, so perhaps I won’t use an explore agent unless necessary.
-
-_Thinking:_
-
-**Planning document execution**
-
-I’m considering using a different approach to draft a plan, but I wonder if that’s really necessary. I need to manage context well and generate a final answer in plain text, noting that we can't create files right now due to active plan mode. It seems essential to present a structured execution plan with document names and dependencies, mentioning the existing workspace and proposing new files. I'll also think about using todowrite to help organize the complex task.
-
-_Thinking:_
-
-**Navigating task guidelines**
-
-I see that the developer guidelines mention not using TodoWrite or Task for commits and PRs, but they can be used for other tasks. However, plan mode restricts modifications and changes, which makes me hesitate about using TodoWrite even for organization. It might be beneficial for tracking progress, but I wonder if it could be interpreted as a system change. Right now, it seems safer to avoid potential issues, and perhaps I should inspect previous conversation compressions later.
-
-_Thinking:_
-
-**Drafting a deliverable plan**
-
-I’m considering reviewing specific sections of the session file, especially around the final startup thesis and previous insights related to Brazil and analytics. Since I have already read the full content, I think I should capture a plan and draft an outline. I could produce a list of deliverables, which might include:
-
-1. `docs/market-memo.md`: Investor-style market memo
-2. `docs/positioning-and-landing-copy.md`
-3. `docs/product-roadmap-12mo.md`
-4. `docs/core-idea.md`
-5. `docs/brazil-market.md`
-
-I wonder if 1 and 4 can be consolidated for efficiency.
-
-_Thinking:_
-
-**Considering language preferences**
-
-I need to figure out if the user wants documentation in English or Portuguese since the Brazilian market documents might be in Portuguese. This could affect the results significantly! While the conversation has been in English, documents used locally in Brazil might warrant using Portuguese. So, I’m thinking I could default to English first but mention that I can adapt to Portuguese. I might ask one question at the end about their preference since it’s important!
-
-_Thinking:_
-
-**Deciding on user questions**
-
-I think it might be good to ask one targeted question. I could say, "My default is to write all documents in English while keeping Brazilian terms like `Pix` and `vale`. If you want the Brazil-focused document in Portuguese, I can switch that and adjust the landing page tone." This approach seems reasonable, but I wonder if asking is necessary. Maybe I can just proceed without a question unless the user indicates a need for it.
-
-_Thinking:_
-
-**Considering compliance and inspection**
-
-I'm thinking about including my default file set, which seems like a good idea. Then I need to consider compliance with the system reminder. I realize that we can only read and inspect, but it feels like I'm on the right track. I appreciate the structure and limits of this system, as it helps keep everything in check while allowing me to focus on what I can do!
-
-_Thinking:_
-
-**Considering language preferences**
-
-If the user prefers Portuguese, the execution would change. They could be bilingual, so I might consider asking a clarifying question like, "Do you prefer English or Portuguese?" But I'm not sure if they would respond right away. The instructions suggest that I should seek their input when weighing trade-offs.
-
-I think I can recommend English for all documents while keeping Brazil-specific terms. If they want a Brazil-focused document in Portuguese, I'd localize it. Using a structured question tool with options like "English (Recommended)," "Portuguese," or "Mixed" could work, but I also need to adhere to guidelines about not asking too many questions.
-
-_Thinking:_
-
-**Evaluating language question usage**
-
-I think we have enough non-blocked work to create a plan. The question tool could potentially help us ask about language preferences. However, it would pause for the user's response, which might complicate things.
-
-I wonder if I could incorporate the plan and the question separately. Using the question tool typically means I wouldn't provide a final response right away, as I’d have to await the user's input. But given the system's preference for a final answer, maybe it's better to avoid using the question tool in this case.
-
-_Thinking:_
-
-**Organizing the plan**
-
-I should mention that no edits have been made, which is good. I’m considering using a heading like **Plan** to be more helpful. Maybe I could add sections like **Deliverables** and **Default Choices**, each with 4-6 concise bullet points. I'll make sure there are no nested bullets, and ensure each section remains clear. Also, the file references should be clickable, like `session-ses_2fe5.md` and `docs/01-core-idea.md`. That sounds solid!
-
-I can’t create the files yet because plan mode is active, but I checked the repo and there’s only one source document, `session-ses_2fe5.md`, so the write plan is straightforward.
-
-**Plan**
-- Create a `docs/` folder and write 5 markdown docs so the material is separated by audience instead of mixed into one long memo.
-- Use `session-ses_2fe5.md:485` as the base startup thesis, `session-ses_2fe5.md:566` for Brazil-first market framing, `session-ses_2fe5.md:587` for roadmap, and `session-ses_2fe5.md:629` plus `session-ses_2fe5.md:641` for partner/regulatory sections.
-- Fold in the earlier competitor work around `DailyPay`, `Branch`, `PayQuicker`, `Hyperwallet`, `CaptivateIQ`, `Caju`, and `Dock` to sharpen the market memo and differentiation.
-- Keep the “core idea” doc as the internal source of truth, and keep the investor memo more narrative and outward-facing so they do not duplicate each other too heavily.
-
-**Deliverables**
-- `docs/01-core-idea.md` — the core parts of the idea: problem, solution, money flow, product layers, revenue model, phased expansion, key risks.
-- `docs/02-brazil-market.md` — Brazil-specific thesis: why Brazil first, `Pix`, `vales`, target verticals, partner types, local regulatory/operational constraints, GTM.
-- `docs/03-market-memo.md` — investor-style memo: market gap, competitor map, wedge, differentiation, why now, business model.
-- `docs/04-positioning-and-landing-copy.md` — sharper messaging: headline options, subheads, value props, employer/employee language, CTA copy.
-- `docs/05-roadmap-12-months.md` — phased roadmap: core ledger + `Pix`, analytics + stored balance, cards, then credit/scale.
-
-**Execution Order**
-- Write `docs/01-core-idea.md` first so the rest share one consistent framing.
-- Derive `docs/02-brazil-market.md` and `docs/03-market-memo.md` from that foundation.
-- Use those to produce `docs/04-positioning-and-landing-copy.md`.
-- Finish with `docs/05-roadmap-12-months.md` so the roadmap reflects the finalized narrative.
-
-**Defaults I’d Use**
-- English for all docs, while keeping local terms like `Pix` and `vales`.
-- Founder/investor tone for `docs/03-market-memo.md`, more operator/practical tone for `docs/02-brazil-market.md`.
-- Core thesis: this is not “another EWA app”; it is a Brazil-native commission ledger with instant access to earned commissions.
-
-If you want, the one choice worth deciding before execution is whether `docs/02-brazil-market.md` should stay in English or be written in Portuguese; otherwise I’d proceed with the defaults above once write mode is available.
-
----
-
-## User
-
-Use pt-br for the brazilian market .md, use english for everything else. Also create an AGENTS.md in the project root so that agents have context on what this project is about
-
----
-
-## Assistant (Build · gpt-5.4 · 14.8s)
-
-_Thinking:_
-
-**Planning file updates**
-
-I’m thinking about creating a plan for tasks and updating their statuses. I might consider using apply_patch for adding multiple new files, which seems good for that purpose. I’m unsure about using Write since it's not currently available. I could script with bash commands, but the developer advises against it for file operations. Still, since I’m creating multiple new files, I guess using apply_patch might be the best option. Also, I should make a todo list and consider compressing old messages.
-
-_Thinking:_
-
-**Considering compression of files**
-
-I'm pondering whether compressing messages m0009 to m0012 is really necessary so soon. The context from the session file is considerable since it’s loaded in the tool output. Technically, the output does consume model space, but I might hold off on compression for now. After creating the documents, it could make sense to compress m0009 to m0013 later. For now, I need to focus on producing the document content before making any compression decisions.
-
-**Tool: todowrite**
-
-**Input:**
-```json
-{
- "todos": [
- {
- "content": "Create core idea doc in English",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Create Brazil market doc in pt-BR",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create investor-style market memo in English",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create positioning and landing copy doc in English",
- "status": "pending",
- "priority": "medium"
- },
- {
- "content": "Create 12-month roadmap doc in English",
- "status": "pending",
- "priority": "medium"
- },
- {
- "content": "Create root AGENTS.md with project context",
- "status": "pending",
- "priority": "high"
- }
- ]
-}
-```
-
-**Output:**
-```
-[
- {
- "content": "Create core idea doc in English",
- "status": "in_progress",
- "priority": "high"
- },
- {
- "content": "Create Brazil market doc in pt-BR",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create investor-style market memo in English",
- "status": "pending",
- "priority": "high"
- },
- {
- "content": "Create positioning and landing copy doc in English",
- "status": "pending",
- "priority": "medium"
- },
- {
- "content": "Create 12-month roadmap doc in English",
- "status": "pending",
- "priority": "medium"
- },
- {
- "content": "Create root AGENTS.md with project context",
- "status": "pending",
- "priority": "high"
- }
-]
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 11.3s)
-
-_Thinking:_
-
-**Planning project structure**
-
-I need to act as a coding agent because the user wants to use Portuguese for the Brazilian market and English for everything else. I'll create an AGENTS.md file in the project root to provide context about the project. I also need to organize a docs directory with five documents plus AGENTS.md. It seems like I'll need to ensure the necessary directories exist first, which could require some Bash commands. After confirming everything’s set, I can move on to file operations.
-
-_Thinking:_
-
-**Structuring the docs directory**
-
-I’m considering using the apply_patch tool to add files in the docs directory, but I’m uncertain if it can create nonexistent directories. To be safer, I should probably use Bash to list the current directories and create the docs folder if it doesn't exist. I might also want to update my to-do list as we progress. Since the context has some stale information, I could compress messages m0010-m0012 later, but for now, I need to focus on writing content in the docs directory.
-
-_Thinking:_
-
-**Verifying directory before creation**
-
-I could use the read command, but the developer instructions suggest using Bash to first verify the parent directory with ls before creating any dirs or files. Since I plan to make the docs directory, it’s better to follow that. I'll run a Bash command with `ls` in the root directory first. After confirming the parent directory exists, I can create docs using `mkdir -p docs`. It seems following these steps will ensure everything is correct. So, first step, let’s do the bash ls in root.
-
-**Tool: bash**
-
-**Input:**
-```json
-{
- "command": "ls",
- "workdir": "/home/alex/projects/payroll",
- "description": "Lists project root contents"
-}
-```
-
-**Output:**
-```
-session-ses_2fe5.md
-
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 66.3s)
-
-_Thinking:_
-
-**Considering documentation process**
-
-I need to create documents and an AGENTS.md file. I have to use specialized tools for file operations, and I think I can use the apply_patch tool for adding multiple files. However, the developer mentioned using Edit and Write, which aren't available, so I'll stick with apply_patch to add files into a new docs directory. Before that, I should verify the parent directory exists with 'ls'. Since 'docs' doesn’t currently exist, I will create it before adding files.
-
-_Thinking:_
-
-**Deciding on documentation approach**
-
-I'm considering whether to compress some stale messages, but maybe I'll hold off on that until after I create the documents. I need to make six docs, including AGENTS.md to provide context for future agents about the project's purpose, documents, and instructions. I must remember to use ASCII only, but since Brazilian Portuguese (pt-BR) can contain accents, it's a bit tricky. While accents might make it look less natural, I wonder if I can write in Portuguese without them. It feels less ideal, but could still achieve clarity.
-
-_Thinking:_
-
-**Clarifying documentation standards**
-
-The instructions indicate that I should only introduce non-ASCII characters when there’s a clear justification, such as writing native Portuguese accurately. Since the file is new and lacks existing non-ASCII characters, I can still use accents for the pt-BR document. I should incorporate hyphenated names for file names and maybe also touch on the competitor map, positioning, and roadmap. I could check the current git status later, perhaps running `git status --short` after edits for verification, but no commit is currently requested.
-
-_Thinking:_
-
-**Structuring documentation**
-
-I'm thinking about how to structure the documentation, organizing it with specific files like "01-core-idea.md" and "02-brazil-market.md." I want to make sure it’s solid but not too verbose. Maybe a docs index could be helpful but I’m not sure it’s necessary. I should probably create the "docs" directory first and then apply patches for the new files. The AGENTS.md should give context about the project, everything from its purpose to the target audience. I’ll need to ensure content is consistent throughout!
-
-_Thinking:_
-
-**Providing project context for agents**
-
-I realize I need to ensure agents have context about the project. I should include instructions to prioritize docs-first edits, keep the Brazil document in Portuguese, and maintain consistent terminology throughout. It's essential to avoid vague terms like "payday lending" or "generic EWA."
-
-In AGENTS.md, I'll touch on the repository structure and the status. Each document should be distinct: the core idea document as the internal source of truth, a market document focused on Brazil, and a market memo for investors, all clearly outlined!
-
-_Thinking:_
-
-**Organizing the market memo**
-
-I think markdown is fine for this, and maybe I should use a table to help organize the information. It’s important to mention specific players and how they differentiate themselves. I might want to keep a memo style, explaining the urgency of "why now," but I won't duplicate the core document too much. Including some risks and reasoning for focusing on Brazil seems essential. Aiming for around 100-150 lines sounds reasonable for clarity!
-
-_Thinking:_
-
-**Creating project documentation**
-
-I'm working on options for creating documentation, like including subheadings, value propositions, and messaging pillars. I need to outline a 12-month roadmap with phases per quarter, focusing on Brazil, mentioning compliance and partnership milestones.
-
-I might create a docs directory with logically numbered file names but I'm not certain about this yet. Keeping it clear, I’ll use plain Markdown and ASCII tables, ensuring to include accents for Brazilian Portuguese files. I'll also think about referencing any existing documents in the AGENTS section to keep everything organized.
-
-_Thinking:_
-
-**Considering content compression**
-
-I'm thinking about compressing messages m0009 to m0015 because the previous content took up a lot of tokens and includes relevant details. I want to preserve the summary from the session read and consider the context, which is still quite large.
-
-I should ensure that crucial information regarding the user’s requests for documentation, specifically for Brazil, is saved. I might compress early messages to maintain clarity and keep boundaries visible, focusing on areas that are stale while retaining what's important.
-
-_Thinking:_
-
-**Analyzing message compression**
-
-I'm looking at the messages and wondering if m0006 is completely empty. It seems like m0008 is also blank, but I can still see important entries like m0009, which is the user's request, and subsequent tool outputs in m0010.
-
-There’s the assistant's reading session in m0011, but I notice m0012 might be blank. I could consider compressing m0009 to m0012, but I want to be careful about including the user's current instruction from m0013 since it’s relevant.
-
-_Thinking:_
-
-**Structuring fintech platform ideas**
-
-I'm breaking down a core idea for a Brazil-first B2B2C fintech platform. The one-liner describes a service that processes customer payments and calculates commissions in real-time, allowing employees to access their earnings instantly through regulated partners.
-
-The main problems addressed involve both employers and employees. My core solution includes a payment processing engine, a commission system, internal ledgers, instant access via Pix, employer settlements, analytics, and future features like cards or stored balances. A neat structure!
-
-_Thinking:_
-
-**Exploring employer-backed advances**
-
-I'm considering the significance of employer-backed advances, mainly because they can replace outdated methods like spreadsheets and manual commission cycles. This approach aligns pay directly with sales events, effectively transforming compensation into a product.
-
-For product architecture, I’m thinking about layers involving payment acceptance, partner banks, ledgers, payouts, and analytics. A money flow example could be illustrating how a customer payment gets split between employees and employers.
-
-I’d define the initial product boundaries, emphasizing it’s not a bank or payroll system. The revenue model might include fees for SaaS, payment processing, and potentially optional payout fees. In terms of phased expansion, I’m envisioning covering commission ledgers first, then analytics, and maybe risk-based credit later.
-
-_Thinking:_
-
-**Identifying key risks**
-
-I’m thinking through the key risks involved in this venture. There are a few critical ones to consider: reversal risk, which may arise from payment disputes, along with commission disputes that could create friction. Labor and regulatory challenges are important, especially since they can affect operations. Partner dependency is another risk; relying too much on partners may cause issues if they don’t perform as expected. Lastly, adoption risk is significant since getting users on board is crucial for success.
-
-_Thinking:_
-
-**Considering design principles**
-
-I’m thinking about design principles. It could be beneficial to focus on earning trust before introducing advanced features, emphasizing transaction-linked truth and partner-led compliance. I should ensure Brazil's operational fit is prioritized, considering employer ROI before consumer monetization. There might be open questions to include, but maybe they aren't that necessary. I need to document the Brazil market in Portuguese, structuring it around key opportunities, reasons for prioritizing Brazil, real pain points, and initial core customers across various sectors.
-
-_Thinking:_
-
-**Exploring sectors for digital payments**
-
-I’m considering sectors that focus on digital payments and transaction attribution. For the value proposition, the benefits to companies include automating commissions, reducing vouchers, improving retention, and enhancing visibility and forecasting. For sellers, I could highlight instant access through Pix, visible balances, and less reliance on informal advances. For the Brazil product version 1, features like onboarding, rule configuration, Pix/card payments, available balances, instant withdrawals, and a dashboard are essential. For go-to-market, partnerships with SaaS, POS, accountants, and franchise networks will be important. Local partners might include banks and BaaS providers.
-
-_Thinking:_
-
-**Considering cooperatives and regional banks**
-
-I'm thinking about including cooperatives and regional banks in my considerations. For payments, I might mention platforms like Pagar.me, Adyen, and Stripe BR. For card services, Dock, Pomelo, and Swap are options. I need to address KYC with providers like idwall and BigDataCorp, and ensure legal and regulatory compliance through local counsel. I should highlight the importance of operating under a partner license, as well as being cautious about wage advances. I’m forming a final thesis that suggests an emerging category: earned commission infrastructure, and I’ll document this in a market memo.
-
-_Thinking:_
-
-**Considering terminology to avoid**
-
-I think I should include some terms to avoid, like "payday loan" and "neobank for salespeople." It might be helpful to mention these in the documentation, so readers are aware of jargon or phrases that could be misleading or harmful. It's important to clarify this information to ensure that we maintain a clear and responsible communication style. Let's see how to best integrate this into the existing material!
-
-_Thinking:_
-
-**Creating a 12-Month Roadmap**
-
-I'm outlining a 12-month roadmap with distinct goals for each stage. The plan includes building a foundation in the first three months, piloting from months four to six, focusing on retention from months seven to nine, and scaling from months ten to twelve. I want to incorporate objectives, products, partnerships, operations, and key metrics such as active earners and retention. It's essential to add decision gates and perhaps a month-by-month overview, while also considering the necessary team buildout.
-
-_Thinking:_
-
-**Structuring AGENTS.md**
-
-I’m thinking about what to include in AGENTS.md. First, a project overview that outlines the product strategy for a Brazil-first commission and payments fintech. My core thesis focuses on payment orchestration, commission ledger, and instant access to earned commissions through regulated partners. The repository map will contain session transcripts and core idea documentation. I'll ensure most docs are in English, while Brazilian market docs are in pt-BR. It's important to maintain consistent terminology and prioritize document updates over speculative code.
-
-_Thinking:_
-
-**Planning Document Structure**
-
-I want to emphasize that there shouldn't be any product code included, as this will benefit future agents. I might consider using a single apply_patch call to handle all file contents, even if it's a bit large. Before that, I should create a docs directory using the bash command `mkdir docs`, confirming the parent directory exists first. I’ve checked the root, so it’s clear to proceed. I’ll ensure the description is concise, around 5-10 words, and draft the content thoughtfully.
-
-**Tool: bash**
-
-**Input:**
-```json
-{
- "command": "mkdir docs",
- "workdir": "/home/alex/projects/payroll",
- "description": "Creates docs directory"
-}
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 195.3s)
-
-_Thinking:_
-
-**Considering project documentation**
-
-I’m thinking about what to include in the repository, like its purpose, key documents, conventions, current strategies, working assumptions, and any open questions. It seems I should update the todo statuses after each file or at least after a patch, as the instructions suggest updating in real time. I might want to mark multiple items as complete or in progress after applying patches. Initially, I should carefully craft the content and maybe create a docs folder for everything.
-
-_Thinking:_
-
-**Considering session files**
-
-I'm contemplating whether I need to read sections of the session file for context, since I've already reviewed the whole file. I might want to reference specific lines in the final output, which is okay. I should mention created docs and verify that files exist after a patch. It might help to compress older message ranges, like m0010-m0011, but since we have the session file content and summary, it may not be necessary just yet.
-
-_Thinking:_
-
-**Exploring payment collection models**
-
-I’m thinking about a payment collection system that includes a commission engine and balances for employees and employers. Instant access through Pix or card payments sounds appealing too. Analyzing how money flows, for instance, with an example of R$1,000, could be really helpful. Then, I’ll want to consider what the revenue model might look like. There’s a lot to unpack here, and I'm excited to dig deeper into this topic!
-
-_Thinking:_
-
-**Exploring core idea for fintech platform**
-
-I’m outlining content for the document focusing on the core idea of a B2B2C fintech platform. The main thesis emphasizes transforming customer payments into real-time commission balances. I’m thinking it’s essential to highlight how this allows employees immediate access to their earned commissions while providing employers with a reliable system for tracking commission payouts and employee performance. This structure should resonate well with potential users and investors!
-
-_Thinking:_
-
-**Outlining fintech solution**
-
-I'm thinking about starting this fintech solution in Brazil but expanding architecture later. The main problem is that commission-heavy employers often calculate payouts manually, settle late, and lack a reliable view of liabilities and performance. Salespeople are left waiting for their earnings, sometimes relying on informal advances.
-
-The solution would involve collecting customer payments and using a rules engine to distribute shares. Employees could cash out instantly, and I'd like to provide analytics for forecasting too!
-
-_Thinking:_
-
-**Evaluating business strategy**
-
-I'm not focusing on being a payroll processor, a general neobank, a payday lender, or a full CRM. The rollout plan starts with offering instant commission access without lending, followed by features like stored balance and analytics, a card, and eventually employer-backed advances or risk-based credit.
-
-I need to consider risks like regulatory boundaries, chargebacks, disputes, labor and tax issues, and reliance on partners. I want to ensure we have proper guardrails in place while formulating our current thesis for the Brazilian market.
-
-_Thinking:_
-
-**Analyzing local challenges**
-
-I'm considering a comparison with Switzerland regarding heavier operations. Locally, there are issues like manual commission closures causing delays in monthly payouts. Companies end up advancing informal "vouchers," and sellers often don't see how much they've already earned. The finance team lacks reliable forecasts too.
-
-For the ideal customer profile, I'm thinking about businesses with commissioned sales teams and digital payments. This might include aesthetic clinics, gyms, educational institutions, retail franchises, telecom resellers, automotive dealerships, real estate, and potentially insurance companies.
-
-_Thinking:_
-
-**Defining value proposition**
-
-I need to narrow it down to about five key elements. For the value proposition, the company calculates automatically, reduces informal "vouchers," improves retention, and provides visibility. For the employees, the benefits include quick access to commission balances, instant Pix transfers, and transparency.
-
-For the initial product version, I'm thinking about features like payment options via Pix, card, or boleto, along with a rule engine, ledger, and balance statuses like "earned," "available," and "liquidated." A management and employee dashboard, audit trails, and perhaps early access percentages would also be essential.
-
-When it comes to local partners, I’m considering financial institutions and BaaS like Dock, QI Tech, and Celcoin, with a potential partnership with Sicredi, although I'm unsure about its role as a sponsor bank.
-
-_Thinking:_
-
-**Mapping the commission ledger**
-
-I’m considering a Brazil-first commission ledger aimed at transforming verified sales into an instantly usable balance.
-
-There's potential in areas like EWA, payout infrastructure, commission software, and Brazil-specific employee finance. The real opportunity is combining real-time payment-linked commission allocation with analytics and worker cash-out.
-
-It’s important to address why this matters now: the rise of Pix, employer needs, and the acceptance of instant money movement.
-
-Ultimately, my focus will be on the unique business model, market strategy, defensibility, and potential risks involved.
-
-_Thinking:_
-
-**Exploring positioning for commission infrastructure**
-
-I’m contemplating adding Switzerland as a secondary market.
-
-In terms of positioning and landing copy, I want to emphasize our core focus on commission infrastructure designed for real-time sales teams. The thesis revolves around turning every verified sale into an immediately accessible balance.
-
-To strengthen our messaging, I’ll highlight real-time commissions, employer controls, worker liquidity, and improved visibility.
-
-Additionally, I'll brainstorm headlines that capture this: like "Turn every sale into an instantly accessible commission."
-
-Finally, the homepage structure will include a hero section, proof strip, feature blocks, and a call to action.
-
-_Thinking:_
-
-**Structuring the 12-Month Roadmap**
-
-I'm thinking about a 12-month roadmap for our project, with phases organized quarterly, focusing on key goals, deliverables, and metrics. Q1 would lay the foundation with essential elements like partner selection and onboarding. In Q2, we could focus on design partners and dashboards. By Q3, I’d like to integrate stored balances and analytics, and finish off with cards and cash flow forecasting in Q4. I'll also consider ways to keep the documentation clear and manageable.
-
-_Thinking:_
-
-**Drafting AGENTS.md Content**
-
-I'm considering whether to read one or two files, but it seems I already have the content from the patch. I need to verify that there are no errors before applying it and carefully craft the patch with the necessary lines. The AGENTS.md can outline our project overview—a B2B2C fintech platform for customer payments and real-time commission calculations. We want to start in Brazil with Pix for instant access, and focus on documentation-first for this project.
-
-_Thinking:_
-
-**Identifying market gaps**
-
-I'm noticing that existing players handle parts of the workflow, but few control the entire process from customer payment through to commission calculation and worker access.
-
-There seems to be a significant gap in the market. Employers with commission-heavy teams often manage payouts manually or face delays in their payroll cycles. This leaves workers wanting immediate access to their earnings, causing them to rely on informal advances. It's clear there's a need for a solution that addresses these issues!
-
-_Thinking:_
-
-**Planning project structure**
-
-I’m considering a multi-entity forecast for partner expansion with a potential employer-backed advance general release. I've outlined metrics like commission GMV, conversion rates, and payout latency, but I shouldn’t go beyond certain scopes, such as standalone consumer lending or full payroll. I might create `docs/01-core-idea.md` to avoid too much duplication while ensuring it serves as a clear internal summary. I need to include a clear money flow block in that document and keep it concise, around 700 lines. Let's build this carefully!
-
-**Tool: apply_patch**
-
-**Input:**
-```json
-{
- "patchText": "*** Begin Patch\n*** Add File: /home/alex/projects/payroll/docs/01-core-idea.md\n+# Core Idea\n+\n+## One-line thesis\n+\n+A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.\n+\n+## The problem\n+\n+### Employers\n+\n+- Commission calculation is often manual, delayed, and hard to audit.\n+- Sales teams ask for informal advances when payroll cycles lag behind real sales activity.\n+- Finance teams struggle to forecast commission liability and reconcile payouts.\n+- Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.\n+\n+### Employees\n+\n+- A sale can happen today, but the commission may not be usable for days or weeks.\n+- Early access to money often depends on asking for an informal advance.\n+- There is rarely a clear view of what has been earned, what is available, and what is still pending.\n+\n+## The product\n+\n+The product sits between customer payment collection and employer payout.\n+\n+1. A customer makes a payment.\n+2. The platform receives the payment event directly, or receives trusted payment data from a partner.\n+3. A commission engine applies employer-defined rules.\n+4. The internal ledger allocates balances between employer and employee.\n+5. A safe portion of the employee's commission becomes available immediately.\n+6. The employee can cash out instantly, and later can also spend from a wallet or card.\n+7. The employer gets the remaining balance on a defined settlement schedule.\n+8. Both sides get visibility into earnings, payouts, and performance.\n+\n+## Core product layers\n+\n+### 1. Payment collection or orchestration\n+\n+- Accept customer payments directly, or integrate with the employer's processor.\n+- Use payment events as the source of truth for commission creation.\n+\n+### 2. Commission rules engine\n+\n+- Support percentage-based, tiered, and custom rules.\n+- Lock an auditable calculation for every sale or payment event.\n+- Track exceptions, reversals, and dispute states.\n+\n+### 3. Ledger and balances\n+\n+- Maintain an internal double-entry ledger.\n+- Track at least three states: `earned`, `available`, `settled`.\n+- Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.\n+\n+### 4. Instant access rails\n+\n+- Phase 1: instant bank transfer or `Pix` cash-out.\n+- Phase 2: stored balance inside the app.\n+- Phase 3: prepaid or debit card linked to the balance.\n+\n+### 5. Employer analytics\n+\n+- Real-time commission liability.\n+- Sales staff performance based on actual money movement.\n+- Forecasts for payouts, reserve needs, and commission trends.\n+\n+### 6. Optional later financing layer\n+\n+- Employer-backed advances.\n+- True risk-based credit only after the business has reliable repayment and reversal data.\n+\n+## Recommended money flow\n+\n+The safest early structure is partner-led custody.\n+\n+- A regulated bank or licensed financial partner holds funds.\n+- The platform owns the application layer, commission logic, ledger, and payout orchestration.\n+- Cards, `Pix`, KYC, and regulated money movement are handled through partners.\n+\n+Example flow:\n+\n+```text\n+Customer pays R$1,000\n+ |\n+ v\n+Partner-held account receives funds\n+ |\n+ v\n+Commission engine calculates split\n+ |\n+ +-- Employee commission: R$200\n+ +-- Employer balance: R$800\n+ +-- Platform fee and reserve logic applied\n+ |\n+ v\n+Employee sees commission balance in app\n+ |\n+ +-- Instant cash-out\n+ +-- Hold balance\n+ +-- Later: card spend\n+```\n+\n+## Product thesis\n+\n+This should not start as a generic wallet, a payroll platform, or a payday loan app.\n+\n+The strongest wedge is:\n+\n+`real-time commission access tied to actual payment events`\n+\n+That positioning matters because it keeps the first product grounded in employer ROI, worker liquidity, and trusted payment data.\n+\n+## Revenue model\n+\n+The business should start with software and money movement economics, not balance-sheet lending.\n+\n+- Platform or SaaS fee for employers.\n+- Take rate or processing fee on payment volume.\n+- Payout fee or bundled payout plan.\n+- Premium analytics tier.\n+- Later: interchange from card spend.\n+- Later: float-sharing or treasury economics if allowed by partner structure.\n+- Much later: advance fee for employer-backed early access products.\n+\n+## What the company is not\n+\n+- Not a general neobank.\n+- Not a full payroll processor.\n+- Not a full CRM or sales engagement tool.\n+- Not a payday lender.\n+\n+The company is best understood as `commission infrastructure`.\n+\n+## Phased expansion\n+\n+### Phase 1\n+\n+- Payment-linked commission calculation.\n+- Employer and employee onboarding.\n+- Ledger with `earned`, `available`, and `settled` states.\n+- Instant payout access.\n+- Employer and employee dashboards.\n+\n+### Phase 2\n+\n+- Stored balance and wallet behavior.\n+- Better analytics and forecasting.\n+- Reserve and holdback controls for refunds and chargebacks.\n+- Early employer-backed advance logic for selected customers.\n+\n+### Phase 3\n+\n+- Card issuance.\n+- Spend directly from balance.\n+- More balance retention and interchange revenue.\n+- Deeper employer integrations.\n+\n+### Phase 4\n+\n+- Multi-entity support.\n+- Broader partner distribution.\n+- Carefully controlled credit products if the data and regulation support them.\n+\n+## Key risks and guardrails\n+\n+### Regulatory boundary\n+\n+- Do not begin by directly holding deposits or acting like an unlicensed financial institution.\n+- Use a licensed partner for custody and regulated money movement.\n+\n+### Reversals and chargebacks\n+\n+- Do not make all commissions instantly withdrawable on day one.\n+- Use availability rules, reserves, and holdbacks.\n+\n+### Commission disputes\n+\n+- Require explicit employer-approved rules.\n+- Preserve a full audit trail for every calculation and adjustment.\n+\n+### Labor and tax treatment\n+\n+- Distinguish `earned access` from `credit`.\n+- Map payroll, withholding, and deduction obligations with counsel before product launch.\n+\n+### Partner dependence\n+\n+- Expect early dependence on bank, card, and processor partners.\n+- Build the ledger and business logic so the company can swap infrastructure providers later.\n+\n+## Current strategic recommendation\n+\n+- Start in Brazil.\n+- Lead with `Pix`-based instant access to earned commissions.\n+- Use partner-led custody and compliance.\n+- Treat stored balances and cards as retention tools, not the initial wedge.\n+- Treat employer analytics as a second major value driver.\n+- Delay true lending until the core ledger and payout engine are reliable.\n*** Add File: /home/alex/projects/payroll/docs/02-brazil-market.md\n+# Tese para o mercado brasileiro\n+\n+## Resumo\n+\n+A melhor entrada para esta ideia no Brasil e uma plataforma B2B2C que conecta recebimento, calculo de comissao, ledger interno e acesso instantaneo ao saldo via `Pix`.\n+\n+O produto inicial nao deve ser vendido como banco digital nem como credito ao consumidor. A tese mais forte e:\n+\n+`transformar cada venda validada em saldo de comissao disponivel quase em tempo real`\n+\n+## Por que o Brasil primeiro\n+\n+- `Pix` ja criou expectativa de movimentacao instantanea e barata.\n+- O mercado convive com atraso no pagamento de comissoes e com o uso informal de `vales`.\n+- Existem instituicoes financeiras, cooperativas, BaaS e emissores abertos a parcerias.\n+- Ha muitos segmentos com equipes comerciais comissionadas e operacao digital crescente.\n+- O argumento de valor e simples: menos atraso, menos friccao operacional e mais retencao do time de vendas.\n+\n+## Dor local que o produto resolve\n+\n+### Para a empresa\n+\n+- Calculo manual de comissao.\n+- Fechamento mensal demorado.\n+- Falta de visibilidade sobre passivo de comissao.\n+- Uso informal de `vales`, com pouca governanca.\n+- Dificuldade para reconciliar recebimento, comissao, estorno e repasse final.\n+\n+### Para o vendedor\n+\n+- Venda feita hoje, dinheiro disponivel so dias ou semanas depois.\n+- Dependencia de `vale` para cobrir caixa pessoal.\n+- Falta de transparencia sobre o que foi ganho, o que esta disponivel e o que ainda esta pendente.\n+\n+## ICP inicial\n+\n+O foco deve ser empresas brasileiras com time comercial comissionado e recebimento digital identificavel.\n+\n+Segmentos promissores:\n+\n+- franquias e operacoes de varejo com vendedores comissionados\n+- clinicas de estetica, odontologia e procedimentos eletivos\n+- academias e servicos recorrentes com equipe de vendas\n+- escolas, cursos e educacao privada com captacao comercial\n+- telecom, distribuicao e revendas com metas e bonificacao variavel\n+\n+## Proposta de valor no Brasil\n+\n+### Para a empresa\n+\n+- Automatizar o calculo e o repasse de comissoes.\n+- Reduzir dependencia de `vales` informais.\n+- Melhorar retencao e motivacao do time.\n+- Ter visao confiavel de performance comercial e custo de comissao.\n+- Ganhar previsibilidade de caixa e de passivo.\n+\n+### Para o colaborador\n+\n+- Ver a comissao quase em tempo real.\n+- Sacar instantaneamente via `Pix` quando o saldo estiver disponivel.\n+- Ter mais clareza sobre metas, historico e projecao de ganhos.\n+- No futuro, usar saldo por cartao sem precisar sacar tudo.\n+\n+## Produto recomendado para o Brasil\n+\n+### V1\n+\n+- recebimento via parceiros de pagamento\n+- motor de regras de comissao\n+- ledger com estados `ganho`, `disponivel` e `liquidado`\n+- saldo para colaborador e empresa\n+- saque instantaneo via `Pix`\n+- dashboard basico para empresa e vendedor\n+- trilha de auditoria por transacao, comissao e ajuste\n+\n+### V2\n+\n+- saldo retido em carteira\n+- analytics de performance e passivo de comissao\n+- regras de reserva para estorno e chargeback\n+- alertas e projecoes\n+- piloto de adiantamento com respaldo do empregador\n+\n+### V3\n+\n+- cartao prepago ou debito\n+- maior retencao de saldo na plataforma\n+- integracoes com ERP, POS, CRM ou software vertical\n+\n+## Parceiros locais que importam\n+\n+### Infra financeira\n+\n+- instituicao de pagamento, banco parceiro ou BaaS para custodia e movimento regulado\n+- exemplos de infraestrutura para avaliar: `Dock`, `QI Tech`, `Celcoin`\n+- cooperativas e bancos menores podem ser parceiros comerciais ou institucionais, incluindo nomes como `Sicredi`, dependendo do modelo\n+\n+### Processamento de pagamentos\n+\n+- parceiros para `Pix`, boleto e cartao\n+- exemplos para avaliar: `Pagar.me`, `Stripe BR`, `Adyen`\n+\n+### Emissao de cartao\n+\n+- exemplos para avaliar: `Dock`, `Pomelo`, `Swap`\n+\n+### KYC e KYB\n+\n+- exemplos para avaliar: `idwall`, `BigDataCorp`\n+\n+### Juridico e regulatorio\n+\n+- escritorio com experiencia em instituicao de pagamento, arranjos de pagamento, `Pix`, LGPD e temas trabalhistas\n+\n+## Consideracoes regulatorias\n+\n+O produto encosta em varias frentes e precisa de mapeamento juridico desde cedo.\n+\n+- Banco Central: estrutura de `Pix`, conta transacional, instituicao de pagamento, regras de reporte e compliance.\n+- Direito do trabalho: natureza da comissao, reflexos em folha, desconto de adiantamentos, regras contratuais com empregador.\n+- LGPD: dados financeiros e de performance do colaborador.\n+- CDC e transparencia: fees, prazos, disponibilidade e regras de estorno.\n+\n+Recomendacao pratica:\n+\n+- comecar debaixo da licenca e da infraestrutura de um parceiro regulado\n+- evitar custodia direta no inicio\n+- evitar vender o produto inicial como emprestimo\n+\n+## Como tratar `vales`\n+\n+No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.\n+\n+Sequencia recomendada:\n+\n+1. acesso ao que ja foi ganho e validado\n+2. liberacao conservadora de parte do saldo antes da liquidacao total\n+3. adiantamento com respaldo do empregador\n+4. so depois, se fizer sentido, credito com underwriting proprio\n+\n+Mensagem correta:\n+\n+- nao: `emprestimo para vendedor`\n+- sim: `acesso controlado a comissao ja gerada`\n+\n+## Go-to-market no Brasil\n+\n+### Primeiro movimento\n+\n+- fechar 5 a 10 design partners com dor forte de comissao e operacao relativamente simples\n+- priorizar empresas em que o evento de venda e facil de mapear ao pagamento\n+- vender para dono, financeiro, operacoes e gestor comercial\n+\n+### Canais de distribuicao\n+\n+- venda direta para SMB e mid-market\n+- parceria com software vertical, POS e adquirencia\n+- grupos de franquia\n+- escritorios contabeis e consultorias de operacao ou folha\n+\n+### Pitch inicial\n+\n+- reduza trabalho manual no fechamento de comissoes\n+- de ao time acesso mais rapido ao que ja foi ganho\n+- troque `vales` informais por um processo auditavel\n+- tenha visao em tempo real de performance e passivo de comissao\n+\n+## Modelo economico mais provavel\n+\n+- fee de plataforma para a empresa\n+- fee por volume processado ou por pagamento conciliado\n+- fee por saque, ou plano com franquia de saques\n+- camada premium de analytics\n+- depois: interchange de cartao\n+- depois: compartilhamento de economia financeira, se permitido pelo arranjo com parceiro\n+\n+## Principais riscos no mercado brasileiro\n+\n+- estorno ou chargeback depois da liberacao da comissao\n+- disputa entre empresa e vendedor sobre regra de comissao\n+- dependencia excessiva de um parceiro bancario ou de BaaS\n+- classificacao regulatoria errada do produto\n+- onboarding ruim para empresa e colaborador\n+\n+## Tese final para o Brasil\n+\n+O melhor posicionamento nao e `mais um app de EWA` e nem `mais um banco digital`.\n+\n+O melhor posicionamento e:\n+\n+`a infraestrutura de comissao em tempo real para empresas brasileiras, com saldo disponivel via Pix e visibilidade operacional para o empregador`\n*** Add File: /home/alex/projects/payroll/docs/03-market-memo.md\n+# Market Memo\n+\n+## Thesis\n+\n+There is a clear product gap between commission software, faster worker payouts, and Brazil-native embedded finance.\n+\n+Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a Brazil-first platform built around real-time commission availability.\n+\n+## The gap in the market\n+\n+Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and informal employee advances. Workers want faster access to earnings. Employers want control, auditability, and better visibility.\n+\n+Existing vendors tend to split into separate categories:\n+\n+- faster pay or earned wage access\n+- payout rails and disbursement infrastructure\n+- commission calculation and analytics software\n+- employee wallet or card experiences\n+- Brazil payment and card infrastructure\n+\n+The opportunity is to combine these into a single workflow built around a verified payment event.\n+\n+## Competitor map\n+\n+| Company | What it does well | Missing piece relative to this idea |\n+|---|---|---|\n+| `DailyPay` | Earned wage access, employee liquidity, employer integrations | Not centered on payment-linked commissions or commission-heavy teams |\n+| `Branch` | Workforce payments, employee app, card, embedded finance | More generic worker finance than commission-specific infrastructure |\n+| `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system and Brazil-specific positioning |\n+| `Hyperwallet` | Global payout orchestration | Infrastructure layer, not a commission system of record |\n+| `CaptivateIQ` | Commission calculation, visibility, forecasting | No native money movement or worker access to balances |\n+| `Caju` | Brazil employee finance and card experience | Not the source of truth for commission creation and payout logic |\n+| `Dock` | Brazil financial infrastructure for accounts, cards, `Pix` | Not a direct competitor; more likely an enabling layer |\n+\n+## What is differentiated here\n+\n+The strongest version of this company is not just a wallet and not just an analytics tool.\n+\n+It is:\n+\n+`a commission ledger that turns verified sales into immediately usable balances`\n+\n+That positioning changes the product in important ways:\n+\n+- the source of truth is a payment event, not a later payroll export\n+- the employer gets workflow, controls, and analytics\n+- the employee gets liquidity without relying on informal advances\n+- the company can monetize software, payment flow, and later retained balances\n+\n+## Why Brazil first\n+\n+Brazil is the more compelling launch market than Switzerland for this specific thesis.\n+\n+- `Pix` makes instant access behaviorally normal.\n+- Informal paycheck advances or `vales` create a visible pain point.\n+- Smaller financial institutions and infrastructure partners may be more open to collaboration.\n+- Commission-heavy SMB and mid-market businesses are common.\n+- The value proposition is concrete and easy to explain.\n+\n+Switzerland may still matter later, but Brazil provides the clearer wedge, larger behavioral advantage, and stronger infrastructure fit for instant commission access.\n+\n+## Recommended wedge\n+\n+The initial product should avoid trying to become a broad payroll platform or a credit-led consumer app.\n+\n+The recommended wedge is:\n+\n+- process or reconcile customer payments\n+- calculate commissions in real time\n+- make a safe portion of earned commissions available immediately\n+- let workers cash out via `Pix`\n+- give employers dashboards, controls, and reporting\n+\n+This creates value for both sides without requiring the company to start as a full lending business.\n+\n+## Differentiation versus adjacent players\n+\n+### Versus `DailyPay` and `Branch`\n+\n+- lead with real-time commission access, not generic earned wage access\n+- use payment-triggered earnings instead of payroll-cycle files\n+- speak directly to commission-heavy employers\n+\n+### Versus `CaptivateIQ`\n+\n+- move from commission visibility to commission execution\n+- turn calculation into money movement and employee utility\n+\n+### Versus `PayQuicker` and `Hyperwallet`\n+\n+- own employer workflows and analytics, not just disbursement rails\n+- focus on Brazil-native behavior and infrastructure\n+\n+### Versus `Caju`\n+\n+- own the commission event and payout logic, not only the employee finance interface\n+\n+## Business model\n+\n+The business should start with software and movement fees, then layer in higher-margin economics over time.\n+\n+Early revenue:\n+\n+- employer platform fee\n+- payment or reconciliation take rate\n+- payout fee or bundled payout plan\n+- analytics tier for larger employers\n+\n+Later revenue:\n+\n+- interchange from card spend\n+- float-sharing or treasury economics if allowed by partner structure\n+- employer-backed advance fees\n+\n+The key is to avoid depending on balance-sheet lending to make the model work.\n+\n+## Go-to-market\n+\n+### Target customers\n+\n+- Brazil-based SMB and mid-market employers with commission-heavy teams\n+- businesses where payment events are digital and attributable\n+- verticals such as franchise retail, clinics, education, auto, telecom, and other sales-led operations\n+\n+### Buyer\n+\n+- owner\n+- finance lead\n+- operations lead\n+- sales manager\n+\n+### Core pitch\n+\n+- reduce manual commission work\n+- reduce informal advances\n+- help retain and motivate sales staff\n+- create a trusted real-time view of commission liability and performance\n+\n+### Distribution channels\n+\n+- direct sales to design partners\n+- vertical SaaS and POS partnerships\n+- franchise groups\n+- accounting and payroll-adjacent referral channels\n+\n+## Defensibility\n+\n+If the company succeeds, defensibility should come from workflow ownership and data position rather than pure infrastructure.\n+\n+- payment-linked truth rather than self-reported sales data\n+- employer-configured commission logic embedded in operations\n+- worker adoption through payout utility and later card usage\n+- analytics built on actual money movement\n+- multi-layer monetization across software, payments, and retention tools\n+\n+## Key risks\n+\n+- payment reversals after employee funds are made available\n+- employer disputes over commission rules\n+- regulatory boundaries around custody, wage access, and credit\n+- dependence on a single bank, BaaS, or card partner\n+- low balance retention if the product offers no reason to keep funds in-platform\n+\n+## Bottom line\n+\n+This idea is attractive because it sits in the overlap of three proven categories: commission software, worker liquidity, and embedded finance.\n+\n+The market does not appear empty, but it still looks fragmented. A Brazil-first product that turns every validated sale into an auditable, instantly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.\n*** Add File: /home/alex/projects/payroll/docs/04-positioning-and-landing-copy.md\n+# Positioning and Landing Copy\n+\n+## Core positioning\n+\n+This company should not present itself as a generic earned wage access app.\n+\n+The stronger frame is:\n+\n+`commission infrastructure for real-time sales teams`\n+\n+## Category statement\n+\n+We help employers turn verified sales into instantly accessible commission balances, with employer controls, worker payouts, and performance visibility built into one system.\n+\n+## Short positioning line\n+\n+Turn every sale into an instantly usable commission balance.\n+\n+## Headline options\n+\n+1. Turn every sale into an instantly accessible commission.\n+2. Give sales teams instant access to earned commissions.\n+3. Real-time commissions for modern sales teams.\n+4. The fastest way to move from customer payment to salesperson payout.\n+5. Commission payouts, employer controls, and worker access in one platform.\n+\n+## Subhead options\n+\n+1. We help employers calculate commissions from real payment events, make safe balances available immediately, and give teams a better way to access what they have earned.\n+2. Replace delayed commission cycles and informal advances with a real-time ledger, instant payouts, and clear employer visibility.\n+3. Built for commission-heavy businesses that want faster payouts, cleaner operations, and better sales performance data.\n+\n+## Product pillar copy\n+\n+### Real-time commission engine\n+\n+Calculate commissions from verified payment events instead of waiting for payroll cycles and spreadsheet reconciliations.\n+\n+### Instant worker access\n+\n+Give employees access to eligible commission balances right away, starting with instant cash-out and later expanding to wallet and card spend.\n+\n+### Employer control and auditability\n+\n+Set payout rules, track reserve logic, and keep a reliable audit trail across every sale, split, payout, and adjustment.\n+\n+### Payment-linked performance data\n+\n+See team performance, commission liability, and payout trends from real money movement rather than disconnected reporting tools.\n+\n+## Employer value props\n+\n+- Reduce manual commission operations.\n+- Replace informal advances with a controlled workflow.\n+- Improve salesperson retention and motivation.\n+- Get a clearer view of commission cost and team performance.\n+- Create a better employee experience without building internal fintech operations.\n+\n+## Employee value props\n+\n+- See what you have earned sooner.\n+- Access eligible commissions faster.\n+- Stop relying on informal paycheck advances.\n+- Track progress and earnings in one place.\n+- Later, spend directly from your balance.\n+\n+## Messaging to avoid\n+\n+- Avoid describing the product as a payday loan.\n+- Avoid leading with float economics or holding customer cash.\n+- Avoid broad claims about replacing payroll or becoming a bank.\n+\n+## Best narrative arc for a homepage\n+\n+### Hero\n+\n+Headline plus a subhead focused on real-time commission access.\n+\n+### Problem section\n+\n+Show the old flow: sale now, commission later, advance requests in between.\n+\n+### Solution section\n+\n+Show the new flow: payment event, commission split, available balance, instant access.\n+\n+### Employer section\n+\n+Focus on automation, controls, and analytics.\n+\n+### Employee section\n+\n+Focus on liquidity, visibility, and trust.\n+\n+### Proof section\n+\n+Use three proof points:\n+\n+- built around verified payment events\n+- instant payout access\n+- auditable employer controls\n+\n+### CTA section\n+\n+Push a design-partner conversation, not a self-serve signup.\n+\n+## CTA options\n+\n+1. Talk to us about your commission workflow.\n+2. See how real-time commission payouts could work for your team.\n+3. Become a design partner.\n+4. Explore a commission infrastructure demo.\n+\n+## Sample hero copy\n+\n+### Option A\n+\n+Headline: Turn every sale into an instantly accessible commission.\n+\n+Subhead: We help commission-heavy businesses calculate payouts from real payment events, give teams faster access to eligible earnings, and keep employer controls and visibility in one place.\n+\n+CTA: Become a design partner\n+\n+### Option B\n+\n+Headline: Real-time commissions for modern sales teams.\n+\n+Subhead: Replace delayed commission cycles and informal advances with a payment-linked ledger, instant payout access, and cleaner employer operations.\n+\n+CTA: See the workflow\n+\n+## Elevator pitch\n+\n+We are building the financial operating layer between customer payments and salesperson earnings. Employers get automated commission calculation and better visibility. Sales teams get faster access to earned commissions. The result is a more trusted, more useful, and more immediate commission system.\n*** Add File: /home/alex/projects/payroll/docs/05-roadmap-12-months.md\n+# 12-Month Roadmap\n+\n+## Guiding principle\n+\n+Do not start by building a broad neobank or a consumer lending app.\n+\n+Start with the smallest product that proves the core wedge:\n+\n+`payment-linked commission calculation plus instant access to earned balances`\n+\n+## Success goal for year one\n+\n+By the end of 12 months, the company should prove that employers will adopt a commission-led payout workflow and that employees will use it for faster access to earnings.\n+\n+The year-one target is not maximum feature breadth. It is proof of product-market fit for the core loop.\n+\n+## Phase 0: Foundation and partner design\n+\n+### Months 0-2\n+\n+#### Objectives\n+\n+- validate the first customer segment\n+- choose partner model for custody, payouts, and compliance\n+- lock the ledger and commission system design\n+\n+#### Workstreams\n+\n+- run design-partner interviews with target employers\n+- map employer commission workflows and exception cases\n+- choose payment and banking partner shortlist\n+- define balance states: `earned`, `available`, `settled`\n+- define reserve and holdback logic for reversals\n+- specify onboarding flows for employers and employees\n+\n+#### Deliverables\n+\n+- product requirements for v1\n+- legal and regulatory issue map\n+- partner shortlist and integration plan\n+- event model for payments, commissions, adjustments, and payouts\n+\n+#### Exit criteria\n+\n+- 5 to 10 serious design partners in pipeline\n+- clear v1 scope that does not depend on lending\n+- chosen path for `Pix` and custody infrastructure\n+\n+## Phase 1: Core ledger and instant payout access\n+\n+### Months 2-5\n+\n+#### Objectives\n+\n+- launch the first working employer flow\n+- prove that a verified sale can become an eligible commission balance\n+- enable instant cash-out for employees\n+\n+#### Product scope\n+\n+- employer onboarding\n+- employee onboarding through partner KYC\n+- payment ingestion or payment reconciliation\n+- commission rules engine\n+- internal ledger\n+- employee balance with `earned`, `available`, and `settled`\n+- employer settlement scheduling\n+- instant payout access via `Pix` or equivalent instant transfer rail\n+- employer dashboard with payout and commission views\n+- employee dashboard with balance and payout history\n+\n+#### Operational scope\n+\n+- manual support for edge cases\n+- conservative limits on instant availability\n+- dispute and adjustment workflows\n+\n+#### Metrics\n+\n+- number of active employers\n+- commission volume processed\n+- payout latency\n+- adjustment and reversal rate\n+- employee activation rate\n+\n+## Phase 2: Analytics and stored balance\n+\n+### Months 5-8\n+\n+#### Objectives\n+\n+- make the product more valuable to employers\n+- improve employee retention of balances\n+- reduce the need for manual reporting\n+\n+#### Product scope\n+\n+- stored balance in the app\n+- clearer balance segmentation and reserve visibility\n+- employer analytics for team performance and commission liability\n+- projections for upcoming payouts\n+- employee insights on earnings pace and history\n+- alerts for anomalies and budget spikes\n+- admin tools for corrections and policy configuration\n+\n+#### Metrics\n+\n+- percent of balances retained in-platform\n+- dashboard usage by employers\n+- frequency of manual interventions\n+- repeat payout behavior per employee\n+\n+## Phase 3: Card and retention tools\n+\n+### Months 8-10\n+\n+#### Objectives\n+\n+- make the balance more useful without requiring immediate cash-out\n+- unlock interchange economics\n+\n+#### Product scope\n+\n+- prepaid or debit card issuance through a partner\n+- spend from available balance\n+- card controls and transaction views\n+- balance retention incentives tied to usage, not explicit interest promises\n+- stronger notifications and mobile experience\n+\n+#### Metrics\n+\n+- card activation rate\n+- card spend volume\n+- balance retention before and after card launch\n+- support load per active user\n+\n+## Phase 4: Scale features and controlled advance pilot\n+\n+### Months 10-12\n+\n+#### Objectives\n+\n+- deepen product value for employers\n+- test a tightly controlled version of advance functionality without becoming credit-led\n+\n+#### Product scope\n+\n+- multi-entity or franchise support\n+- API or integration layer for ERP, CRM, or POS tools\n+- employer cash flow forecasting\n+- pilot of employer-backed advances with strict limits\n+- improved risk rules for refunds, clawbacks, and employee exits\n+\n+#### Metrics\n+\n+- employer expansion within existing accounts\n+- integration adoption\n+- advance usage and repayment behavior\n+- loss or exception rate on pilot advances\n+\n+## What should stay out of scope in year one\n+\n+- standalone consumer lending\n+- full payroll replacement\n+- broad international expansion\n+- feature-heavy consumer banking experience\n+- deep CRM functionality\n+\n+## Year-one product philosophy\n+\n+The roadmap should stay disciplined.\n+\n+- build the commission ledger first\n+- prove instant access to earned money second\n+- add retention tools third\n+- add credit only after the company has the data and controls to support it\n+\n+## Recommended milestone sequence\n+\n+1. prove employer demand for payment-linked commission automation\n+2. prove worker demand for instant access to eligible balances\n+3. prove safe operating rules around reversals and disputes\n+4. prove that analytics improves employer retention\n+5. prove that cards increase balance retention\n+6. only then test employer-backed advance products\n*** Add File: /home/alex/projects/payroll/AGENTS.md\n+# AGENTS.md\n+\n+## Project overview\n+\n+This repository is a documentation-first workspace for a startup concept.\n+\n+The startup thesis is a B2B2C fintech platform that processes or reconciles customer payments, calculates commissions in real time, gives employees fast access to earned commissions, and gives employers better controls and analytics around commission payouts.\n+\n+## Current strategic thesis\n+\n+- Start in Brazil.\n+- Lead with `Pix`-based instant access to earned commissions.\n+- Use a regulated financial partner for custody, payouts, card issuance, and compliance.\n+- Treat cards and stored balances as later retention tools, not the initial wedge.\n+- Treat advances as a later employer-backed feature, not the first product.\n+- Build employer analytics from payment-linked data.\n+\n+## What this company is\n+\n+- commission infrastructure\n+- a ledger and payout orchestration layer\n+- an employer workflow product with employee financial utility\n+\n+## What this company is not\n+\n+- not a generic neobank\n+- not a full payroll processor\n+- not a full CRM\n+- not a payday lender\n+\n+## Repository status\n+\n+- There is no production code yet.\n+- The repo currently stores strategy and planning documents.\n+- `session-ses_2fe5.md` is the raw source transcript that inspired the current docs.\n+\n+## Key documents\n+\n+- `docs/01-core-idea.md` - canonical summary of the product and business model\n+- `docs/02-brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR\n+- `docs/03-market-memo.md` - competitor map, differentiation, and investor-style memo\n+- `docs/04-positioning-and-landing-copy.md` - messaging and homepage copy directions\n+- `docs/05-roadmap-12-months.md` - phased roadmap for the first year\n+\n+## Language conventions\n+\n+- Write in English by default.\n+- Keep `docs/02-brazil-market.md` in pt-BR.\n+- Keep fintech terminology consistent: `Pix`, `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.\n+\n+## Product assumptions to preserve\n+\n+- Early architecture should rely on a licensed partner rather than direct custody.\n+- The safest wedge is real-time access to earned commissions, not general lending.\n+- The payment event is the source of truth for commission creation whenever possible.\n+- The employer buyer needs controls, auditability, and analytics, not just a payout rail.\n+- The employee experience matters because faster access and later card usage can improve retention and platform utility.\n+\n+## Reference competitors and adjacent players\n+\n+Use this current market framing unless new evidence clearly changes it:\n+\n+- `DailyPay`\n+- `Branch`\n+- `PayQuicker`\n+- `Hyperwallet`\n+- `CaptivateIQ`\n+- `Caju`\n+- `Dock`\n+\n+These companies validate parts of the stack, but the current thesis is that few combine payment-linked commissions, worker liquidity, employer controls, and Brazil-native rails into one product.\n+\n+## Prioritization guidance for future agents\n+\n+- Prioritize docs and plans that sharpen the Brazil-first wedge.\n+- Keep the distinction between `earned access` and `credit` very clear.\n+- Prefer practical operator language over generic fintech buzzwords.\n+- If you extend product plans, sequence features conservatively: ledger and instant payouts first, analytics and stored balance second, cards third, employer-backed advances later.\n+\n+## Open areas worth exploring later\n+\n+- deeper regulatory mapping for Brazil launch structure\n+- partner comparison across BaaS, payment processors, and card issuers\n+- pricing design for employers versus workers\n+- reserve rules for refunds, disputes, and chargebacks\n+- target vertical selection and design-partner outreach strategy\n*** End Patch"
-}
-```
-
-**Output:**
-```
-Success. Updated the following files:
-A docs/01-core-idea.md
-A docs/02-brazil-market.md
-A docs/03-market-memo.md
-A docs/04-positioning-and-landing-copy.md
-A docs/05-roadmap-12-months.md
-A AGENTS.md
-```
-
----
-
-## Assistant (Build · gpt-5.4 · 16.3s)
-
-_Thinking:_
-
-**Considering documentation updates**
-
-I'm thinking about whether to include accents in pt-BR for readability, but I might stick with default ASCII unless there's a clear reason. I should update the statuses for all tasks since they’re done. After that, maybe I'll read through some docs to confirm everything. I also wonder if I should check file presence or just run a quick listing. I think I could compress some earlier context, particularly from range m0005 to m0012.
-
-_Thinking:_
-
-**Reviewing documentation status**
-
-The task is closed because the user requested docs, and we inspected the repo and provided a plan. However, I'm wondering if we might still need additional details. Although it could be unnecessary to compress now due to the current context length being moderate, the instructions suggest compressing steadily. I think I could compress the messages from m0005 to m0012, but it seems like m0006 is already a compressed section from earlier.
-
-I created the docs set and added agent context at the repo root.
-
-- Added the core concept doc in `docs/01-core-idea.md`
-- Added the Brazil-specific thesis in pt-BR in `docs/02-brazil-market.md`
-- Added the investor-style market memo in `docs/03-market-memo.md`
-- Added positioning and landing copy in `docs/04-positioning-and-landing-copy.md`
-- Added the phased first-year plan in `docs/05-roadmap-12-months.md`
-- Added project guidance for future agents in `AGENTS.md`
-
-A few content choices I baked in:
-- Brazil-first wedge: `Pix` + real-time earned commission access
-- Partner-led custody/compliance instead of direct fund holding
-- Cards and stored balance later, not day one
-- Employer-backed advances later, with clear separation from lending
-- Employer analytics as a major second value driver
-
-No tests or builds were relevant here since this repo is docs-only right now.
-
-Natural next steps:
-1. I can tighten these into a more investor-ready narrative and make the docs feel more consistent in tone
-2. I can add a `06-partner-landscape.md` comparing Brazil BaaS, payment, card, and KYC partners
-3. I can turn this into a simple landing page or pitch deck structure based on `docs/04-positioning-and-landing-copy.md`
-
----
-
diff --git a/sessions/session-ses_2fe5.md b/sessions/session-ses_2fe5.md
deleted file mode 100644
index 2e5b879..0000000
--- a/sessions/session-ses_2fe5.md
+++ /dev/null
@@ -1,705 +0,0 @@
-# Payment processing with early commission payouts and bank partnerships
-
-**Session ID:** ses_2fe58810cffeU8IzEZHZRCZF25
-**Created:** 3/18/2026, 3:54:07 PM
-**Updated:** 3/18/2026, 4:18:46 PM
-
----
-
-## User
-
-The core of the idea is: a company that process payments and pays out commissions to employees before sending the money to employers
-However there are some other parts of the idea that I'm still not sure how to put together, for example:
-1) Partnering with banks so that they hold the money and manage that
-2) What are the technologies we can use to process payments
-
----
-
-## Assistant (Plan · gpt-5.4 · 24.6s)
-
-A cleaner way to frame the idea is:
-
-- A business receives customer payments.
-- Your platform calculates commissions owed to employees from those payments.
-- The funds are held with a regulated bank partner, not by you directly.
-- Your system instructs payouts to employees first, then sends the remaining balance to the employer.
-
-That gives you a clearer model: payment orchestration + commission ledger + regulated banking partner.
-
-What usually fits best
-
-- `You` are the software and workflow layer: calculate splits, track balances, trigger payouts, reporting.
-- `Bank partner` holds the money in safeguarded/FBO-style accounts and handles regulated money movement.
-- `Payment processor` collects the incoming payment.
-- `Payout rails` send money to employees and employers.
-
-How the bank partnership piece usually works
-
-- You generally do not want to custody funds yourself early on.
-- Instead, partner with a sponsor bank or Banking-as-a-Service provider.
-- The bank holds funds, manages compliance requirements around accounts/movement, and settles transactions.
-- Your platform keeps a ledger of who is owed what and sends payment instructions through APIs.
-
-Typical model
-
-- Customer pays `1000`.
-- Your rules engine says employee commission = `200`.
-- Bank-held account receives `1000`.
-- Platform ledger records:
- - employee payable `200`
- - employer payable `800`
-- Payout engine sends `200` to employee, `800` to employer.
-
-Key legal/regulatory point
-
-- This starts to look like `payments + payroll + earned commissions`, so regulation matters a lot.
-- Depending on geography, you may touch:
- - money transmission
- - payroll/wage laws
- - KYC/KYB/AML
- - card/network rules
- - tax reporting
-- So the safest early approach is usually: `bank + licensed payment partners + your software layer`, rather than becoming the regulated entity yourself.
-
-Tech stack options
-
-- **Payment acceptance**
- - `Stripe`, `Adyen`, `Checkout.com`
- - Good for cards, basic ACH, merchant onboarding
-- **Banking / money movement**
- - `Stripe Treasury`, `Modern Treasury`, `Moov`, `Increase`, `Dwolla`
- - Good for ACH, wires, RTP, virtual accounts, balance tracking
-- **Identity / compliance**
- - `Plaid` for bank linking
- - `Alloy`, `Persona`, `Sardine` for KYC/KYB/fraud
-- **Ledger / commissions engine**
- - Internal double-entry ledger
- - Or tools like `Modern Treasury Ledgers`, `Formance`, `TigerBeetle`
-- **Core app stack**
- - Backend: `Node.js/TypeScript`, `Python`, or `Go`
- - DB: `PostgreSQL`
- - Queue/workflows: `BullMQ`, `Temporal`, `SQS`
- - Audit/reporting: event log + immutable ledger tables
-
-A practical MVP shape
-
-- Employer onboarding
-- Employee onboarding
-- Payment collection
-- Rules engine for commission calculation
-- Internal ledger for split accounting
-- Manual or scheduled payouts
-- Dashboard for balances, payouts, disputes, reports
-
-Best first partnership strategy
-
-- Start with a provider that already has bank relationships and payout rails.
-- Don’t begin by negotiating directly with a large bank unless you already have scale.
-- A common sequence is:
- 1. use `Stripe/Adyen` for incoming payments
- 2. use `Modern Treasury/Moov/Increase` for payout orchestration
- 3. add direct bank relationships later if volume justifies it
-
-The hardest parts are usually not the code
-
-- commission rule complexity
-- timing of fund availability
-- reversals/chargebacks
-- compliance and licensing boundaries
-- disputes between employee and employer
-- tax and payroll treatment of commissions
-
-If you want, I can next help with one of these:
-1. turn this into a one-paragraph startup description
-2. design the full product/payment flow step by step
-3. suggest a concrete MVP stack for building this in 3 months
-
----
-
-## User
-
-Right, so what I am thinking is having accounts for the employers and employees and credit money to their accounts in our system when we receive the payments. We need to find a way to incentivise them to leave their money with us for as long as possible to earn interest off off the cash that we're holding. One way I was thinking of doing this is by having credit/debit cards for the users so that they could spend their money directly from their account, while still leaving the option for them to wire that money to their own bank account. I'm considering starting this company in either switzerland or brazil, given that I have people in both countries that I could leverage and bring into this startup. I don't know much about the swiss market, but I know that the brazilian market currently has some smaller banks that seem eager to find partnerships to gain market share, Sicredi for example. Also, in brazil we have PIX which makes wiring money fast and cheap, which could be a great selling point, something along the lines of being able to tell the sales staff that they can instantly have access to their commissions the moment the customer makes a payment.
-
----
-
-## Assistant (Plan · gpt-5.4 · 34.2s)
-
-You’re moving from “commission payout software” toward a much bigger model: `stored balances + instant access + cards + bank transfers`. That can be powerful, but it changes the company a lot.
-
-The key strategic split
-
-- If you only calculate commissions and trigger payouts, you’re mainly a software/payments orchestration company.
-- If you hold balances in user accounts, let them keep funds, offer cards, and earn yield on float, you start to look like a fintech / neobank / regulated money business.
-
-That second version is much more valuable, but much harder.
-
-What I think is strongest in your idea
-
-- The best wedge is not “we hold your money.”
-- The best wedge is “salespeople get instant access to commissions the moment a sale clears.”
-- In Brazil, that pitch is especially strong because `PIX` makes instant movement normal and expected.
-- A card attached to the balance makes the money feel immediately usable, which is a real behavioral incentive not to cash out.
-
-Important caution on “earning interest off the cash”
-
-- This is attractive economically, but it is also where regulation gets much more serious.
-- You generally cannot just “hold client money and earn interest on it” however you want.
-- You need to be very clear on:
- - who legally holds the funds
- - whether funds are customer assets or your operating cash
- - whether yield/interest belongs to the customer, the bank, or your platform
- - whether your product becomes regulated as stored value, e-money, deposit-like activity, or money transmission
-- So the safer version is usually:
- - partner bank or licensed institution holds funds
- - your platform maintains the subledger and user experience
- - cards and transfers are issued through licensed partners
- - your economics come from interchange, SaaS, take rate on processing, float-sharing agreement if allowed, and treasury arrangements
-
-Your proposed product architecture
-
-- Employer account in your app
-- Employee account in your app
-- Incoming payment lands into safeguarded/partner-held funds
-- Your ledger allocates the split instantly
-- Employee sees commission balance immediately
-- Employee can:
- - spend with card
- - transfer out to bank
- - maybe keep balance for future spending
-- Employer receives remaining balance on schedule or instantly
-
-That is a coherent product.
-
-Why Brazil looks stronger than Switzerland for the first launch
-
-- `PIX` is a huge distribution advantage for instant payouts.
-- User behavior already accepts real-time transfers.
-- Smaller financial institutions may be more open to partnerships.
-- The pain point around delayed commission access feels easier to explain.
-- Switzerland is wealthy and credible, but likely harder as a first market unless you already have strong local regulatory and banking access.
-
-My default view: start in `Brazil`, not Switzerland, unless your Swiss network includes real bank/compliance operators.
-
-Why cards are smart
-
-- A card makes the balance useful without forcing bank withdrawal.
-- That increases retention of funds in the system.
-- It also creates interchange revenue.
-- It changes the product from “payout tool” to “financial home for commission earners.”
-
-But cards should probably be phase 2, not day 1.
-
-Recommended rollout
-
-1. `Phase 1`: instant commission ledger + PIX payout
-- receive merchant payment
-- calculate split
-- show employee available commission immediately
-- let employee cash out instantly via PIX
-- let employer settle on schedule
-
-2. `Phase 2`: stored balance
-- employee can keep balance in app
-- employer can hold operating balance for future payouts
-- basic wallet behavior
-
-3. `Phase 3`: card issuance
-- prepaid/debit card tied to stored balance
-- spend directly from commission account
-- optional employer expense or draw features later
-
-4. `Phase 4`: treasury economics
-- negotiated bank yield/float arrangements
-- maybe employer incentives for keeping balances
-- maybe employee rewards instead of explicit interest
-
-Better incentive framing
-
-Instead of saying “leave money with us so we earn interest,” design the product so users naturally keep balances because it is useful:
-
-- instant commission availability
-- free PIX transfers
-- card spend with cashback/rewards
-- early access to future commissions
-- bill pay / payroll-like convenience
-- employer bonuses for keeping payout reserves on platform
-
-That is commercially cleaner and safer to message.
-
-Core risks you should think through now
-
-- **Regulatory boundary**: are you software, payment institution, wallet, or something deposit-like?
-- **Fund timing**: when is money truly available vs still reversible?
-- **Chargebacks/refunds**: what happens if you already paid the employee?
-- **Labor law**: are instant commissions legally “earned wages,” “advances,” or something else?
-- **Partnership dependence**: your bank/program manager/card issuer can become a bottleneck.
-- **Unit economics**: instant payouts and card programs only work if fees, fraud, and support stay under control.
-
-My practical recommendation
-
-- Build the company narrative around `instant commission access infrastructure for employers and sales teams`.
-- Start with `Brazil`.
-- Use `PIX` as the hero feature.
-- Do not make “we profit from holding your cash” the public core story.
-- Structure the first version with a licensed financial partner holding funds.
-- Add cards only after the payout/ledger engine works reliably.
-
-A clean positioning statement
-
-- “We help companies collect payments and give sales teams instant access to earned commissions, with employer and employee balances managed through regulated financial partners.”
-
-If you want, I can next do one of these:
-1. turn this into a proper startup thesis and business model
-2. map the exact money flow and partner stack for a Brazil-first launch
-3. compare Brazil vs Switzerland in a founder-style decision memo
-
----
-
-## User
-
-One practice that is quite common place in Brazil, that this company could potentially reduce, but probably not eliminate is what they call "vales", which are essentailly advances on their paycheck. I think there's good potential in also making it a feature in the business, letting employees borrow against their paycheck for a small fee/interest.
-
----
-
-## Assistant (Plan · gpt-5.4 · 19.7s)
-
-That can be a strong feature, but it splits into two very different products:
-
-- `Earned wage access` — employees withdraw commission/pay already earned but not yet settled.
-- `Consumer credit` — employees borrow against expected future paycheck/commission.
-
-Those look similar in the app, but operationally they are very different.
-
-My recommendation
-
-- Start with `earned commission access`, not lending.
-- Treat it as “access to already-earned money” whenever possible.
-- Only explore true advances/credit later, once you have repayment data and employer integrations.
-
-Why this matters
-
-- `Earned access` is easier to explain: “you already earned it, we just make it available sooner.”
-- `Lending` creates heavier risk around underwriting, defaults, collections, regulation, and reputation.
-- In Brazil, a product that feels like replacing `vales` is attractive, but you do not want to become just another salary-advance lender.
-
-Best product framing
-
-- Employee makes a sale.
-- Payment is received or sufficiently authorized.
-- Your engine calculates commission instantly.
-- A safe portion becomes `available now`.
-- Employee can:
- - withdraw via `PIX`
- - spend via card
- - keep balance in wallet
-- For amounts not yet fully settled, you can show:
- - `available now`
- - `pending settlement`
- - `future estimated commissions`
-
-That lets you reduce `vales` without promising money too early.
-
-Rollout path
-
-1. `Phase 1: Early access to earned commissions`
-- no true loan
-- only release funds tied to clear sales/payment events
-- set conservative availability rules
-
-2. `Phase 2: Employer-backed advances`
-- employer opts in
-- employer agrees payroll deduction / settlement logic
-- advance limits based on verified earnings history
-
-3. `Phase 3: Risk-based credit`
-- only if economics and regulation make sense
-- requires underwriting, loss reserves, collections, disclosures
-
-Key design choice
-
-- Use `employer-backed advance` before `standalone consumer lending`.
-- If the employer contract helps recover advances from payroll/commissions, risk drops a lot.
-- That keeps the product closer to B2B2C infrastructure than pure retail credit.
-
-Big risks to solve
-
-- **Settlement risk**: what if customer payment reverses after employee got paid?
-- **Commission disputes**: what if employer later changes the commission amount?
-- **Legal classification**: earned wage access vs credit product
-- **Collections**: what happens if employee leaves the company?
-- **Abuse**: employees repeatedly pulling advances before reversals/refunds are known
-
-Practical guardrails
-
-- Only advance against `verified and rule-locked` commissions
-- Keep a reserve/holdback for refunds and chargebacks
-- Cap instant access to a percentage, not 100%, at first
-- Require employer integration and approval
-- Price it as a transparent convenience fee, not compounding debt
-- Avoid language that makes it sound like payday lending
-
-Strong positioning
-
-- “We help companies eliminate informal paycheck advances by giving employees controlled, instant access to earned commissions.”
-
-What I’d plan next
-
-- Define three balance states: `earned`, `available`, `settled`
-- Make `PIX instant cash-out` the core Brazil feature
-- Keep wallet/cards as retention tools
-- Defer true lending until you have data on repayment, reversals, and employer behavior
-
-If you want, I can next do one of these:
-1. draft a Brazil-first product roadmap including this feature
-2. map the risk rules for `earned access` vs `advance`
-3. write a founder memo on why this should start as EWA, not lending
-
----
-
-## User
-
-Another part that I think can be valuable to companies is the possibility of giving them information on the performance of sales staff through amount of commissions, projections, some other forms of telemetry, etc
-
----
-
-## Assistant (Plan · claude-opus-4.6 · 28.4s)
-
-That's a natural extension and it gives the product a second value proposition beyond money movement: `sales intelligence powered by real transaction data`.
-
-Why this is strong
-
-- You already have the data because payments flow through your system.
-- Most commission tracking today lives in spreadsheets or disconnected CRMs.
-- Employers currently have to reconstruct sales performance from multiple sources.
-- Your platform sees the actual money, so your data is inherently more trustworthy than self-reported CRM entries.
-
-What you can offer
-
-**Real-time dashboards for employers**
-
-- Total commissions paid per employee, team, region, period
-- Revenue per salesperson
-- Average deal size and frequency
-- Commission cost as percentage of revenue
-- Top performers vs underperformers
-- Trends over time (weekly, monthly, quarterly)
-
-**Projections and forecasting**
-
-- Projected commission liability for the month based on current pace
-- Expected payout amounts before settlement
-- Seasonal patterns and trend analysis
-- Cash flow forecasting for the employer (how much they need in the system to cover upcoming payouts)
-
-**Employee-facing insights**
-
-- "You've earned X this month, Y this quarter"
-- Progress toward targets or tiers
-- Comparison to personal history
-- Estimated next payout
-
-**Alerts and anomalies**
-
-- Sudden drop in an employee's sales
-- Unusually high refund/chargeback rate for a salesperson
-- Commission costs trending above budget
-- Employees approaching advance limits
-
-**Operational telemetry**
-
-- Time from sale to commission availability
-- Payout speed and method distribution
-- Cash-out frequency per employee
-- Balance retention rates
-
-Why this matters strategically
-
-- Analytics transforms your product from `payment plumbing` into `business intelligence`.
-- It makes the employer the buyer, not just the payer.
-- It increases switching costs — once employers rely on your dashboards, leaving is harder.
-- It opens a path to premium/enterprise pricing tiers.
-
-Important nuance
-
-- The analytics should come from data you already collect through payment processing.
-- Do not try to become a full CRM or HR platform.
-- Stay focused on `money-linked sales performance`, not general employee management.
-
-How it fits in the product
-
-| Layer | What it does |
-|---|---|
-| Payment engine | Collect, split, settle |
-| Ledger / wallet | Track balances, enable instant access |
-| Cards / PIX | Make money usable |
-| Analytics | Make the data useful to employers |
-
-The analytics layer is essentially free to build incrementally because the underlying data already exists in your ledger. It's a reporting and visualization problem, not a data collection problem.
-
-Pricing angle
-
-- Basic analytics included in the platform fee
-- Advanced analytics (projections, anomaly detection, custom reports, API access) as a premium tier
-- That gives you a SaaS-like revenue stream alongside transaction-based revenue
-
-Recommended approach
-
-- Ship basic dashboards early — even simple charts increase perceived value significantly.
-- Add projections and alerts as you accumulate enough historical data.
-- Let employer feedback drive which analytics matter most.
-- Do not over-invest in analytics before the core payment/payout engine works.
-
-At this point, the full product vision is becoming clear:
-
-1. **Payment collection** — employer receives customer payments through you
-2. **Commission engine** — rules-based split calculation
-3. **Instant access** — employees see and use earned commissions immediately
-4. **Wallet + cards + PIX** — money stays in system, usable without withdrawal
-5. **Earned wage access / advances** — reduce informal "vales"
-6. **Sales analytics** — employer gets performance intelligence from real payment data
-7. **Float economics** — platform earns from balances, interchange, fees
-
-That is a coherent, defensible fintech product.
-
-Do you want me to now pull all of this together into one of these:
-1. A structured startup thesis / business model document
-2. A phased product roadmap with priorities
-3. A technical architecture plan for building the MVP
-
----
-
-## User
-
-1
-
----
-
-## Assistant (Plan · claude-opus-4.6 · 59.7s)
-
-
-
-Here is the structured startup thesis and business model.
-
----
-
-# Startup Thesis: Instant Commission Infrastructure
-
-## One-liner
-
-A B2B2C fintech platform that sits between employers and sales staff, processing customer payments, instantly calculating and distributing commissions, and providing financial accounts with cards and instant transfers — while earning from float, interchange, fees, and SaaS.
-
----
-
-## Problem
-
-**For employers:**
-- Commission calculation is manual, error-prone, and delayed.
-- Payroll cycles create lag between a sale and the salesperson getting paid.
-- Informal advance practices ("vales") are unstructured, create accounting friction, and expose the company to risk.
-- Visibility into sales performance is fragmented across CRM, payroll, and spreadsheets.
-
-**For employees (sales staff):**
-- Commissions arrive days or weeks after the sale.
-- Accessing earned money early requires asking for informal advances.
-- No single place to see earnings, track performance, or manage commission income.
-
----
-
-## Solution
-
-A platform that:
-
-1. Receives customer payments on behalf of the employer.
-2. Instantly calculates the commission split using employer-defined rules.
-3. Credits the employee's account with earned commission in real time.
-4. Lets employees spend (card), transfer (PIX), or hold their balance.
-5. Settles the employer's share on their preferred schedule.
-6. Provides both sides with analytics, projections, and reporting.
-
----
-
-## How money flows
-
-```
-Customer pays R$1,000
- │
- ▼
-┌─────────────────────────┐
-│ Partner bank / FBO │ ← Regulated entity holds funds
-│ account receives funds │
-└─────────────────────────┘
- │
- ▼
-┌─────────────────────────┐
-│ Platform ledger splits │
-│ Employee: R$200 │
-│ Employer: R$800 │
-│ Platform fee: deducted │
-└─────────────────────────┘
- │ │
- ▼ ▼
- Employee acct Employer acct
- (available now) (settles on schedule)
- │
- ├── PIX cash-out (instant)
- ├── Card spend (interchange)
- └── Hold balance (float)
-```
-
----
-
-## Revenue model
-
-| Stream | Description | Phase |
-|---|---|---|
-| **Transaction fee** | % or flat fee on each payment processed | 1 |
-| **PIX/transfer fee** | Small fee per cash-out (or free with limits) | 1 |
-| **Float income** | Interest/yield on balances held with bank partner | 2 |
-| **Card interchange** | Revenue share on card transactions | 3 |
-| **Advance fee** | Flat fee for early access to not-yet-settled commissions | 2 |
-| **SaaS tier** | Premium analytics, custom rules, API access, multi-entity | 2 |
-
-The strongest early revenue is likely `transaction fee + advance fee`. Float and interchange grow with balance retention and card adoption.
-
----
-
-## Target market (Brazil first)
-
-**Initial segment:**
-- Small and mid-size companies with commission-based sales teams (5–200 salespeople).
-- Industries: retail, insurance, real estate, auto dealers, door-to-door sales, telecoms resellers.
-
-**Why Brazil:**
-- PIX makes instant transfers a baseline expectation.
-- "Vales" culture creates a clear pain point to solve.
-- Smaller banks (e.g., Sicredi, cooperatives) are actively seeking partnerships to grow.
-- Large underbanked/underserved workforce in commission-based roles.
-- Regulatory environment has a clear framework for payment institutions.
-
-**Why not Switzerland first:**
-- Harder to find flexible bank partners without existing scale.
-- Smaller addressable market for commission-heavy sales forces.
-- Higher regulatory and operational costs to start.
-- Consider Switzerland as a second market or for a different product angle (e.g., wealth/treasury for employers).
-
----
-
-## Product roadmap
-
-### Phase 1 — Core (months 1–4)
-- Employer onboarding and configuration
-- Employee onboarding (KYC via partner)
-- Payment collection (PIX, boleto, card via payment processor)
-- Commission rules engine (percentage, tiered, custom)
-- Internal double-entry ledger
-- Employee balance: `earned` / `pending` / `settled`
-- PIX instant cash-out for employees
-- Employer settlement on schedule
-- Basic employer dashboard (commissions paid, per-employee breakdown)
-- Basic employee dashboard (earnings, available balance, cash-out history)
-
-### Phase 2 — Retention + advances (months 4–7)
-- Employee wallet with stored balance
-- Earned wage access: early access to earned-but-unsettled commissions
-- Employer-backed advance feature (payroll-deductible)
-- Reserve/holdback logic for refunds and chargebacks
-- Employer analytics: performance trends, projections, commission cost ratios
-- Employee insights: earnings pace, personal trends
-- Alerts: anomalies, budget thresholds, refund spikes
-- Premium SaaS tier for analytics
-
-### Phase 3 — Cards + scale (months 7–12)
-- Prepaid/debit card issuance (via card program manager)
-- Card spend from commission balance
-- Interchange revenue
-- Float optimization with bank partner
-- Multi-entity / franchise support
-- API for employer system integrations (ERP, CRM, POS)
-- Employer cash flow forecasting
-
-### Phase 4 — Expansion (12+ months)
-- Risk-based credit / true advances (if regulation allows and data supports)
-- Employee rewards / cashback programs
-- Second market entry (Switzerland or other LatAm)
-- Employer expense management features
-- White-label or embedded finance partnerships
-
----
-
-## Key partnerships needed
-
-| Partner type | Role | Examples (Brazil) |
-|---|---|---|
-| **Sponsor bank / BaaS** | Hold funds, compliance, account infrastructure | Sicredi, QI Tech, Dock, Celcoin |
-| **Payment processor** | Accept PIX, boleto, cards | Pagar.me, Stripe BR, Adyen |
-| **Card issuer / program manager** | Issue prepaid/debit cards | Dock, Pomelo, Swap Financial |
-| **KYC/KYB provider** | Identity verification | idwall, BigDataCorp |
-| **Legal / regulatory counsel** | Payment institution licensing, labor law | Local fintech law firm |
-
----
-
-## Regulatory considerations (Brazil)
-
-- **Payment institution license**: likely needed if holding client funds or issuing payment instruments. Can potentially operate under a bank partner's license initially.
-- **Central Bank oversight**: PIX participation rules, reporting obligations.
-- **Labor law**: commission classification, payroll deduction rules for advances, tax withholding obligations.
-- **Consumer protection (CDC)**: transparency on fees, right to information.
-- **LGPD**: data protection for employee financial data.
-- Early recommendation: operate under a licensed partner's umbrella, pursue your own license when volume justifies it.
-
----
-
-## Core risks
-
-| Risk | Mitigation |
-|---|---|
-| Settlement reversal after payout | Holdback reserves, conservative availability windows |
-| Commission disputes | Employer-signed rules, audit trail, dispute workflow |
-| Employee default on advances | Employer-backed payroll deduction, conservative limits |
-| Bank partner dependency | Contractual protections, plan for multi-partner |
-| Regulatory classification | Legal counsel from day 1, operate under licensed partner |
-| Fraud / identity | KYC at onboarding, transaction monitoring |
-| Low balance retention | Card + UX incentives to keep funds in-platform |
-
----
-
-## Unit economics sketch (per employer, per month)
-
-Assuming: 20 employees, R$500 avg commission, 80% cash-out rate
-
-| Item | Value |
-|---|---|
-| Total commissions processed | R$10,000 |
-| Transaction fee (2%) | R$200 |
-| Advance fees (10% of employees, R$5 each) | R$10 |
-| Float income (20% retained, ~1% monthly yield) | R$20 |
-| Interchange (Phase 3, est.) | R$15 |
-| **Monthly revenue per employer** | **~R$245** |
-| Target: 200 employers | **~R$49,000/mo** |
-
-These are rough and conservative. The real leverage comes from larger employers and higher retention rates.
-
----
-
-## Competitive positioning
-
-- Not a payroll company. Not a bank. Not a CRM.
-- "Commission infrastructure" — the financial operating system between employer payments and sales team earnings.
-- Closest comparisons internationally: `Earned wage access` (DailyPay, Caju, Xerpay) crossed with `payment splitting` (Stripe Connect model) crossed with `sales performance analytics`.
-- Differentiation: you process the actual payment, so you have the most trustworthy data and the fastest path to commission availability.
-
----
-
-## Founding team needs
-
-- **Product / business lead**: understands the employer sales pain, can sell to mid-market companies.
-- **Engineering lead**: can build ledger, payment integrations, real-time systems.
-- **Fintech / regulatory lead**: understands Brazilian payment institution rules, bank partnerships, compliance.
-- Ideally, at least one founder with direct relationships at potential bank partners.
-
----
-
-That covers the thesis, model, market, roadmap, risks, and economics. Want me to go deeper on any section, or move toward technical architecture or a specific partnership strategy?
-
----
-