A clear next step starts here.

Preview with your business website or start manually. Review detected facts and suggested terms. Save explicitly to create your workspace, verify your email, and continue the saved program through Offer, Connect, and Review & launch.
Open setup →

Your rate, duration, currency, and hold should be clear before acceptance. Explain which purchases qualify and show a worked earning example. Existing qualified referrals keep their accepted economics; a new default is not a silent rewrite.
Explore a sample receipt →

Create an isolated test in Program setup → Connect. Use a separate test signing key and the exact fictional referral, amount and currency from its receipt. Refresh to compare expected and calculated commission. Tests never credit real partner earnings. Stripe tests use your sandbox account; publication also requires verified live-account and endpoint binding. Advanced signed-event integrations require a separate live-key configuration probe. Changed offers or keys require current evidence.
Open tracking test console →

Check delivery, signature, referral identity, partner readiness, accepted terms, currency, and earning window in that order. A duplicate is not another earning. Keep the original event reference and open Activity diagnostics before retrying.
Read the Stripe guide →

Review the exact partner, currency, eligible amount, and payment reference. Pay through your own method, then explicitly record that payment. Exporting a list does not settle an obligation. Keep payment evidence and any refund adjustment in the history.
See the sample payment record →

The generic server-to-server endpoint accepts stable event IDs, conversion or refund type, positive integer amount_cents, currency, customer_ref, and a referral reference. Refunds reference original_event_id. Authentication uses x-philos-signature. Request the current contract and workspace endpoint before implementation; never send unsigned production events.
Read the signed-event guide →

Create a scoped key in workspace Settings, connect your MCP client, and read its available tools. Keep the key private. A member’s live role limits their agent’s access. Revoke a key in the same settings when it is no longer needed.
Read the agent guide →

Expired: links and codes last 30 minutes; request a fresh one for the same email. Used: each link works once, and a new request replaces earlier unused ones, so open the most recent message. Another device: the eight-digit code only works in the browser that requested it; request a new link on the device you are using, or open the email link there. Wrong account: if you are signed in as someone else, sign out and switch deliberately. Resend: a new request is available 60 seconds after the last one. Do not share a sign-in link or paste it into support messages.
Workspace sign-in →

Workspace sign-in accepts your email and password, Google, GitHub, or a one-time email link. Google and GitHub sign you in with the verified email on that account, so it must match your workspace email. Forgot password: choose Forgot password?, enter your email and a new password, then enter the eight-digit code we email you in the same browser. The new password takes effect only then. Add or change a password in Account → Password; saving one asks you to verify your email again first. After eight wrong passwords in 15 minutes, password sign-in for that email pauses for 15 minutes; an emailed link still works. Payouts, team changes and other sensitive actions can still ask you to verify by email.
Workspace sign-in →

Expired: links and codes last 30 minutes; request a fresh one with the email you applied or were invited with. Used: each link works once, and a new request replaces earlier unused ones, so open the most recent message. Another device: the eight-digit code only works in the browser that requested it; request a new link where you are, or open the email link there. Wrong account: use the address the merchant invited, or sign out and switch deliberately. Resend: a new request is available 60 seconds after the last one. Never forward a sign-in link to the merchant or support.
Partner sign-in →

Submitted means the merchant has your application. Approved may still require email verification, terms acceptance, or identity evidence. Wait until your portal says Ready to share before using a referral link. Contact the merchant if a decision needs clarification.
Partner sign-in →

Held earnings have a release condition. Payable earnings are eligible for the merchant’s payment process. Recorded paid means the merchant paid you outside Philos and recorded that payment; Philos does not verify bank delivery. Refunds can create separate adjustments, even after payment.
Explore partner earnings →

Open Help in the merchant’s partner portal so support has the right program context. Include the earning or payment reference and a short description. Do not include bank credentials, identity documents, or secret login links in ordinary email.
Open your programs →