Rewards, Payments, and Platform Ledger

Draft 0.1 — 2 August 2026
ANUKA’s internal ledger is an accounting and orchestration layer. It is not automatically a bank account, custodial wallet, escrow account, prepaid account, or statement of legal ownership of funds.

Objective

ANUKA must make money movement as legible as contribution history.

Every dollar should be traceable from:

• payer;
• commercial purpose;
• payment processor event;
• platform fee;
• product allocation;
• contributor or reviewer allocation;
• reserve, refund, dispute, or transfer;
• tax and accounting record.

Payment principles

1. Use regulated payment infrastructure rather than rebuilding payment rails.
2. Keep the internal ledger double-entry and auditable.
3. Separate authorization, charge, allocation, earnings, transfer, payout, refund, and dispute.
4. Never show an amount as withdrawable before it is actually available under the payment-provider and platform rules.
5. State merchant-of-record and loss responsibility per transaction type.
6. Do not call delayed transfers escrow without a lawful structure.
7. Do not make tokens a prerequisite for ordinary payments.
8. Treat tax, sanctions, fraud, and identity controls as product requirements.

Core financial records

Commercial order

Why money is being paid:

• bounty funding;
• sponsored feature;
• subscription;
• usage charge;
• product purchase;
• service milestone;
• stewardship fee;
• platform fee;
• refund or adjustment.

Payment intent or charge

The payment-provider object representing customer payment authorization and collection.

Allocation

The internal plan for dividing gross funds.

Ledger entry

An immutable accounting entry with debit, credit, currency, source event, actor, and timestamp.

Earnings record

An amount earned under acceptance or outcome rules but not necessarily paid out.

Transfer

Movement from the platform account to a connected account.

Payout

Movement from a connected account to an external bank account or eligible payout destination.

Reserve

An amount temporarily unavailable to cover refunds, disputes, delayed acceptance, or risk.

Refund

Return of payment to the original payment method where supported.

Reversal

Recovery of a prior transfer or allocation.

Dispute

A cardholder or payment-network challenge with separate evidence and liability rules.

Recommended Stripe Connect model

ANUKA already has Stripe Connect capabilities and should reuse them.

The platform must choose the charge model per product flow.

Direct charges

The connected account charges the customer directly.

Use when:

• the resident product should be merchant of record;
• the connected account manages its customer relationship;
• product-level financial separation is preferred.

Destination charges

The platform creates the charge and transfers proceeds to one connected account, optionally retaining an application fee.

Use when:

• one product or provider receives the main allocation;
• the platform controls the checkout;
• platform-level dispute and loss responsibilities are accepted.

Separate charges and transfers

The platform charge and later transfers are separate, allowing multiple recipients or delayed allocation.

Use when:

• multiple contributors share one funded feature;
• recipient allocation is not fully known at purchase time;
• milestone transfers occur later.

This model requires a strong ledger. The platform may be merchant of record and is exposed to refunds, disputes, fees, and negative balances depending on configuration.

Account model

Every paid participant or resident product receives an appropriate connected account before payout.

The onboarding flow may collect:

• legal identity or entity data;
• address;
• tax information;
• beneficial owners or representatives;
• bank account;
• capabilities;
• terms acceptance;
• sanctions and compliance information.

ANUKA should use Stripe-hosted or embedded onboarding where possible rather than storing sensitive identity and bank data itself.

Ledger accounts

Recommended internal accounts include:

Asset accounts

• Stripe platform available;
• Stripe platform pending;
• payment receivable;
• refund receivable;
• recoverable transfer;
• processor reserve.

Liability accounts

• sponsor refundable funds;
• product payable;
• contributor payable;
• reviewer payable;
• steward payable;
• tax payable;
• customer credits;
• disputed funds;
• unclaimed payouts.

Revenue accounts

• platform application fees;
• SaaS subscriptions;
• usage fees;
• verification fees;
• marketplace service fees;
• premium support.

Expense accounts

• payment processing;
• dispute fees;
• refunds not recoverable;
• contributor incentives;
• promotional credits;
• tax-filing costs;
• fraud losses.

Balance types

The UI must use precise labels.

Project budget

Funds allocated for product use under campaign or owner rules.

Pending sponsor funds

Collected payments that remain refundable or unallocated.

Committed budget

Funds reserved for assignments or milestones.

Earned amount

Compensation accepted under the applicable terms.

Pending transfer

An earned amount awaiting risk, identity, tax, or payment-provider conditions.

Connected-account balance

Balance held and managed within Stripe for the connected account.

Withdrawable payout

Amount Stripe currently allows to be paid out.

Product credits

Non-cash usage rights whose transferability, expiry, and refundability are explicitly defined.

ANUKA balance by itself is prohibited because it hides legal meaning.

Example allocation

A customer funds a feature with $1,000.

Illustrative allocation:

• gross payment: $1,000;
• payment fee: $35;
• sales tax: $60;
• refundable contingency reserve: $55;
• product implementation budget: $650;
• testing and review budget: $100;
• ANUKA platform fee: $100.

The actual ledger records processor events and final fees rather than relying only on estimates.

State machine

CREATED
→ AUTHORIZATION_PENDING
→ AUTHORIZED
→ PROCESSING
→ PAID
→ ALLOCATED
→ COMMITTED
→ EARNED
→ TRANSFER_PENDING
→ TRANSFERRED
→ PAYOUT_PENDING
→ PAID_OUT

Alternative branches:

FAILED | CANCELED | PARTIALLY_REFUNDED | REFUNDED | DISPUTED | REVERSED | FROZEN

Earnings rules

An amount becomes earned only after the applicable trigger:

• deliverable acceptance;
• milestone acceptance;
• completed qualified review;
• released feature;
• measured outcome;
• stewardship period completion;
• contractual date.

A UI progress bar is not an earning event.

Payout holds

Payouts may be delayed for:

• payment settlement;
• asynchronous payment confirmation;
• refund window;
• identity or tax completion;
• sanctions or fraud review;
• dispute;
• milestone review;
• reserve policy;
• connected-account restriction.

Every hold must have a reason code, owner, expected review path, and participant-facing explanation where lawful.

Fees

ANUKA fee types may include:

• application fee percentage;
• fixed transaction fee;
• subscription;
• usage-based integration or AI fee;
• verification fee;
• managed-service fee;
• dispute or exceptional-support fee where lawful and disclosed.

Fees must be visible before commitment and represented separately in the ledger.

Refunds and reversals

A refund workflow must coordinate:

• customer refund;
• connected-account transfer reversal;
• platform-fee treatment;
• tax adjustment;
• sponsor and contributor records;
• campaign state;
• reputation claims.

For indirect Connect charges, Stripe can debit the platform for refunds and disputes. The platform may need to reverse transfers to recover funds from connected accounts.

Disputes and negative balances

The charge type and Connect controller configuration determine who responds and whose balance is debited.

Where the platform is merchant of record or liable for connected-account losses, ANUKA must maintain:

• reserves;
• risk limits;
• dispute evidence;
• transfer-reversal rights;
• negative-balance policy;
• account suspension rules;
• loss accounting.

A product’s positive displayed earnings must not ignore an active dispute.

Tax reporting

Stripe Connect may assist with U.S. 1099 reporting, but responsibility depends on account and fee configuration.

The platform must determine:

• whether payments are nonemployee compensation, payment-card transactions, royalties, prizes, or another category;
• whether Form 1099-NEC, 1099-MISC, 1099-K, or another form applies;
• federal and state thresholds;
• taxpayer identification requirements;
• backup withholding;
• correction workflow;
• cross-border reporting.

Stripe states that in some Connect configurations the platform, not Stripe, is responsible for relevant 1099 forms.

Sales and marketplace taxes

Per product and jurisdiction, determine:

• seller;
• marketplace facilitator;
• taxable product or service;
• sourcing location;
• exemption handling;
• collection and filing responsibility;
• refund tax treatment.

Stripe Tax can calculate and report transactions, but it does not decide the legal liable party for ANUKA.

Sanctions and geographic restrictions

Payment and reward products require risk-based sanctions controls.

Controls may include:

• connected-account verification;
• OFAC screening;
• geography and IP risk signals;
• blocked-country and prohibited-party restrictions;
• transaction monitoring;
• manual escalation;
• blocked and rejected transaction procedures;
• record retention.

OFAC emphasizes that digital and traditional payments have the same sanctions obligations and recommends tailored risk-based programs.

Currency

The ledger records original currency and settlement currency separately.

Rules must cover:

• FX rate source;
• conversion timing;
• who bears FX cost;
• refund currency differences;
• cross-border availability;
• minimum transfer amounts;
• rounding.

Idempotency and reconciliation

All payment webhooks must be idempotent.

Daily reconciliation SHOULD compare:

• Stripe charges;
• refunds;
• disputes;
• transfers;
• reversals;
• connected-account balances;
• payouts;
• internal ledger totals;
• tax records.

No manual dashboard edit should silently bypass accounting history.

Audit log

Material financial changes record:

• actor;
• role;
• event source;
• previous state;
• new state;
• amount and currency;
• reason;
• related object;
• approval;
• time;
• correction relationship.

Security

• never store raw card data;
• use provider-hosted payment elements;
• protect webhook signatures;
• rotate API keys;
• separate test and production;
• use least-privilege restricted keys;
• require step-up authentication for payout changes;
• delay payout destination changes where appropriate;
• alert on unusual transfers;
• require dual approval above thresholds.

MVP acceptance criteria

• Stripe Connect reuse;
• explicit charge model per flow;
• double-entry ledger;
• precise balance labels;
• application fees;
• milestone earnings;
• connected-account payouts;
• refund and transfer reversal;
• dispute state;
• reserves;
• tax identity collection;
• 1099 responsibility mapping;
• sanctions and fraud controls;
• daily reconciliation;
• no claim that internal balances are bank deposits or escrow.

Sources

• Stripe Connect — Build a marketplace
• Stripe Connect — Separate charges and transfers
• Stripe Connect — Application fees
• Stripe Connect — Refunds and disputes
• Stripe Connect — Risk and liability management
• Stripe Connect — U.S. tax reporting
• Stripe Tax with Connect
• OFAC — Framework for Compliance Commitments
• OFAC FAQ 560

Verification record

• Sources opened and checked: 2 August 2026
• Protocol status: Founding draft
• Accounting review required: Yes
• Tax review required: Yes
• Payments and money-transmission review required: Yes