Revenue Model¶
Status: LOCKED 2026-05-06 — Model 3 (marketplace facilitator). This is the authoritative description of how Portugal Odyssey earns money at MVP launch and how money moves between customer, platform, and partner. Supersedes the 2026-04-28 options paper (A/B/C patterns).
1. At a glance¶
Portugal Odyssey is a marketplace facilitator (Modelo 3 in Portuguese travel-business taxonomy). The platform connects travelers with independent partners; partners deliver and bill the service; PO takes a commission on the customer's payment.
| Question | Answer |
|---|---|
| Who quotes the price to the customer? | The partner (via their service in the partner-service catalog). PO does not add a visible markup. |
| Who charges the customer's card? | Stripe, on behalf of the partner's connected account, with PO retaining an application fee. |
| Who issues the factura (invoice) to the customer? | The partner, using their own AT-certified invoicing system (TOConline, Moloni, InvoiceXpress, Vendus, Primavera, etc.). PO does not invoice customers. |
| Who is the Merchant of Record? | The partner. PO is a facilitator, not an intermediary travel agency. |
| Does PO need RNAVT registration? | No, not for MVP launch — Model 3 sidesteps RNAVT obligations (saves ~€2-4k/year fixed costs while pre-revenue). |
| What does PO invoice and to whom? | PO invoices the partner for the commission earned per booking (B2B invoice from Experiências100Fim to the partner's NIF). |
2. Money flow¶
Stripe Connect destination charges with an application fee. Implemented in services/payment-service (Plan #020 Slice C-prime, shipped 2026-05-06).
Customer card
│ full booking price
▼
Stripe PaymentIntent (created with transfer_data.destination = partner's
│ connected account ID;
│ application_fee_amount = PO commission)
▼
Partner connected account (Stripe Express)
│ net = full price − application_fee_amount − Stripe fees
▼
Partner's bank (Stripe payout schedule)
─── parallel ───
PO application fee (held in PO's Stripe balance)
│
▼
PO bank (Stripe payout schedule)
Why destination charges (not separate-charges-and-transfers). Destination charges keep the partner as the Merchant of Record on Stripe's side — the customer's card statement shows the partner's name, the partner's payment_intent lives in their dashboard, and Stripe issues a Connect-account receipt under the partner's brand. PO is purely the platform fee collector. This is the structural piece that makes Model 3 work and keeps PO out of the RNAVT-required regime.
3. Invoicing — who invoices whom¶
| Direction | Issued by | To | Mechanism | Status |
|---|---|---|---|---|
| Factura for the booked service | Partner (each one, independently) | Customer | Partner's own invoicing system (any AT-certified PT software). PO does not interact with this flow. | Out of scope for PO engineering. Partner-side operational requirement. |
| Stripe receipt | Stripe Connect (auto) | Customer | Auto-emailed from the partner's Connect account when the PaymentIntent succeeds. Informational only — not a factura. | Live (Stripe default). |
| Commission factura | Experiências100Fim, Unipessoal Lda | Partner (B2B) | PO's chosen invoicing system (see §4). PO issues one factura per partner per period for the accumulated commission. | Pending invoicing-system choice (see §4 + Riff coming out of Ask 3 in f1-responses). |
Engineering implication: payment-service does not generate facturas. The booking → factura emission is a partner-side responsibility surfaced in partner onboarding docs (separate Riff). PO's own commission-invoicing chain is a successor plan to #020 (~Plan #025-equivalent).
4. Commission¶
| Aspect | Value | Status |
|---|---|---|
| Charging mechanism | application_fee_amount on Stripe PaymentIntent (destination charge) |
Live in services/payment-service since Slice C-prime |
| Default rate (sandbox + early launch) | TBD — needs Cristina decision before live customers. Working assumption for sandbox: flat 10%. | Open client decision |
| Per-category rate variation? | Likely a single flat rate at launch; per-category differentiation deferred to post-launch when there is data to justify it. | Open client decision (default: single flat rate) |
| Commission invoicing platform | PO invoices the partner; partner does not invoice PO. Chosen platform TBD (likely TOConline once Cristina+Paulo confirm scope) | Open (Ask 3 in f1-responses) |
| VAT on commission | 23% (general services, PT). Cross-border partners gated on EU OSS decision (Ask 4 in f1-responses). | Open ([Ask 4 in f1-responses]) |
5. Refund policy¶
Refunds flow through Stripe's split-refund mechanism — the application fee is refunded pro-rata by default when a destination-charge PaymentIntent is refunded. Engineering side is wired (services/payment-service refund endpoint, Plan #020 Slice D).
Customer-facing cancellation tiers — still open client decisions (no change since 2026-04-28):
| Question | Provisional default (subject to Cristina confirmation) |
|---|---|
| Free-cancellation window before service date? | 48h before service start → full refund |
| Partial-refund tier? | 24-48h before service → 50% refund |
| No-refund tier? | <24h before service → 0% refund |
| Force-majeure handling? | Full refund regardless of window if the partner cancels |
| PO commission on refunded bookings? | PO retains 0% (refund the full application fee) — fair to partner |
| Customer chargeback rights? | Always honoured (Stripe-mediated) |
These provisional defaults need to be encoded both in customer-facing T&C copy (Cristina sign-off) and as concrete code paths in payment-service + booking-service (engineering Riff once defaults locked).
6. Future migration trigger — when Model 3 stops fitting¶
Model 3 is the right choice while pre-revenue. As revenue scales, the trade-off shifts:
| Metric | Stay on Model 3 | Switch to Model 1 (agências de viagens, RETA) |
|---|---|---|
| Annual gross commission revenue | < ~€40k | > ~€40-50k (RNAVT + IDD-insurance fixed costs become small enough as a percentage) |
| Customer-facing positioning | "Marketplace of independent partners" | "Curated trip-builder PO is responsible for end-to-end" (different value prop) |
| Refund / dispute liability | Partner-side primary; PO mediates | PO-side primary; PO holds reserves |
| Operator complexity | Low (no RNAVT, no IDD-insurance contract, no per-trip bond) | Substantial (RNAVT + IDD + annual reports + supervisory inspections) |
Trigger: when annualised gross commission revenue (12-month trailing) crosses ~€40k AND there is operational appetite for the RNAVT + IDD overhead. At that point, file a "Model 3 → Model 1 migration" plan that covers: RNAVT registration, IDD-insurance procurement, payment-service refactor to direct customer billing under PO's NIF, factura issuance from PO to customer for the full price, partner-payout pipeline (PO holds money longer), MoR liability posture.
Until then: do not build Model 1 features speculatively. The destination-charge flow + partner-issues-factura is the entire revenue plumbing for MVP.
7. What is explicitly NOT being built for MVP¶
Listed because the 2026-04-28 options paper considered them and Model 3 rules them out (for now):
- ❌ Featured placement / paid prominence — conflicts with brand stance (Identity Proposal: "no sponsored row, no commission-based re-ranking").
- ❌ Customer-side premium subscription — not in MVP scope.
- ❌ API / data licensing — MCP surface exists technically but no commercialisation plan.
- ❌ Referral / affiliate kickbacks — defer; attribution is too brittle pre-launch.
- ❌ Partner subscription / SaaS fees — Pattern B from the original options paper is not the chosen model.
- ❌ PO-issued customer facturas — the partner does this. Building a PO invoice template for customers would be wasted work (and would imply MoR, which contradicts Model 3).
8. Open client decisions (narrowed)¶
What remains for Cristina to lock before live launch:
- Default commission rate — single flat % for MVP. Working assumption 10%; needs explicit confirmation + sign-off on
t&c.mdline item. - Refund policy tiers — confirm or amend the §5 provisional defaults. Required for customer-facing T&C copy.
- PO's commission-invoicing platform — TOConline scope clarification with Paulo Bandeira (Ask 3 in f1-responses). Successor plan once decided.
- EU OSS registration — Paulo Bandeira call covering place-of-supply rules for PO commission (Ask 4 in f1-responses).
- Annual revenue review cadence — when to re-evaluate the Model 3 → Model 1 trigger above. Suggest 6-month checkpoint post-launch.
What is already decided (not open anymore): the model itself (Model 3), the payment flow (destination charges), the invoicing direction (partner-issues-factura), no RNAVT for MVP, no IDD insurance for PO, no PO-issued customer facturas.
9. References¶
docs/clients/legal/f1-responses.md— VAT identity, per-category mapping, TOConline scope, EU OSS open items + the 2026-05-06 Model 3 lock entrydocs/clients/legal/f1-vat-oss-brief.md— original VAT/OSS framing for the TOC discussiondocs/implementation-plans/020-payment-merchant-of-record/— payment-service Stripe Connect implementation (Slice C-prime = Model 3 switch)docs/implementation-plans/024-booking-flow/— booking flow (model-agnostic; works under both Model 3 and a future Model 1)docs/branding/IDENTITY-PROPOSAL.md— brand stance on no-sponsored-contentdocs/clients/legal/gdpr-posture.md— Stripe data flows + partner DPA implications