1 · Create card-link session idle
How to test (Cycle 0 — operator subscription): pick SUBSCRIPTION, set amount (e.g. 138) → Create session → Open hosted card page → enter the test card 4508 7500 1574 1019 (exp 01/30, CVV 123) → back here, Fetch session status (step 3) → Charge off-session (step 4).
—
2 · Link a card on Xendit's hosted page
Open the hosted page above, enter the test card 4508 7500 1574 1019 (exp 01/30, CVV 123, any name/email), complete linking. You'll be redirected back (an "INVALID_SESSION_STATUS" page just means the one-time session was used — that's success).
3 · Captured token none
No webhook configured yet → use Fetch session status to pull the token directly from Xendit.
—
—
4 · Off-session charge idle
Charges the captured token via /v3/payment_requests. Expect SUCCEEDED, frictionless (no 3DS).
—
Cycle 1 · Payments & refunds idle
How to test: Refund needs a successful charge first (Cycle 0 step 4). Deposit hold — Capture and Void are two alternatives on one hold, not a sequence: click Authorize (→ AUTHORIZED), then either Capture (take it → SUCCEEDED) or Void (release it → CANCELED). You can't Void after a Capture — to test Void, click Authorize again for a fresh hold, then Void. Each needs the saved token. ⚠️ Deposits: a card hold is only a short pre-auth (~7 days) — a real tenancy deposit held for months must be a captured payment held in the balance, then refunded (release) or kept (forfeit) at tenancy end.
—
Cycle 2 · Sub-account provisioning idle
How to test: List accounts (✓ shows test sub-accounts) → paste a LIVE id into the box → Set active (used as for-user-id in Cycles 3/5). Create MANAGED is expected to ✗ until Xendit enables MANAGED for Octovis — that's a known prod blocker, not a bug.
—
Cycle 3 · Platform fee / commission idle
How to test: 1) Create fee rule (✓ returns xpfeeru_…). 2) Create fee-applied PAY session (✓ returns a hosted URL) → optionally Open and pay with a test card to see the platform skim the fee. Needs an active sub-account (Cycle 2).
—
Cycle 4 · Multi-party split (co-broking / financing) split rule
How to test: each row = a party getting a slice (flat or % of the payment) routed to their sub-account. Pre-filled with a co-broking example (2 agents + platform fee). + Add party for more — leader override(s), 2nd leader, financier (Octovis or operator), landlord. The remainder goes to the operator (the active for-user-id sub-account). Then Create split rule → Create split session → Open & pay to see the fan-out. (Each payee needs its own MANAGED sub-account in prod; rows here reuse test accounts. 100% total fails — leave a remainder.)
| party / role | destination sub-account id | unit | amount |
|---|
—
Cycle 5 · Landlord payouts idle
How to test: Check balance (✓ shows the sub-account float) → Pay out a small amount (✓ ACCEPTED, returns disb-…). Try a huge amount to see the D5 cap reject it (✗ "exceeds balance" — that's the cap working). Pays from the active sub-account (Cycle 2).
—
Distribute via payouts (agent commissions) payouts
The payout alternative to splits (Cycle 4) — for payees who only have a bank account (agents, leaders, external landlords); no sub-account needed. Each row fires one payout from the operator's balance. Total is D5-capped. Pre-filled with a co-broking example. (Prod: pay out only settled funds; each payout has a fee.)
| payee | bank channel | account number | amount |
|---|
—
Cycle 6 · Webhooks inbound
How to test: 1) In the Xendit test dashboard → Settings → Developers → Callbacks, set the URL below for the products you want (Payment Sessions, Recurring/Subscriptions, Payouts, Refunds). 2) Trigger an action (link a card, pay out, refund). 3) Events appear below within seconds (auto-refreshes). ✓ = verification token matched.
Webhook URL: https://xendit-sandbox.octovis.com/webhook · shared test account — register only events v2 doesn't use (sessions / recurring / payouts / refunds).
— no webhooks received yet —
Cycle 7 · Collection channels channels
How operators choose what tenants see: tick the channels to display, then Create session — they're passed as allowed_payment_channels (the operator's choice, per session). Activation is per-account: a channel the operator hasn't activated with Xendit returns INVALID_PAYMENT_CHANNEL naming it — that's your "needs activation" signal. On this test account only CARDS is activated; tick FPX/VA/etc. to see the activation message.
—