BloxClips docs

Appearance

Whop sandbox validation ​

Audit date: 2026-09-01.
Result: Blocked validation — no Whop API request or transfer was attempted. There are no sandbox-confirmed claims in this documentation set.

What was inspected safely ​

  • Process environment variable names and backend configuration shape, without printing values.
  • Bloxclips-backend/.env.template, which defines generic/production-labeled WHOP_API_KEY, WHOP_COMPANY_ID, WHOP_COMPANY_ROUTE, and WHOP_WEBHOOK_SECRET variables.
  • Presence—not contents—in a local backend .env of Whop-related variables.
  • The backend Whop client, which does not configure a sandbox base URL or an explicit API environment guard.
  • Installed @whop/sdk 1.0.14 types and official sandbox documentation.

No configured value proved all of the following together:

  1. the key is a sandbox-only key;
  2. the base URL is https://sandbox-api.whop.com/api/v1;
  3. the configured origin is a sandbox biz_…/ldgr_… owned by BloxClips;
  4. a consenting sandbox creator user_… recipient exists;
  5. sandbox ledger transfers are enabled.

The official sandbox guide says payout functionality is unavailable. It does not clearly distinguish external Payouts from ledger Transfers. Calling the existing generic key against either host would therefore risk using a production credential or making an unsupported money request. Per task constraints, the audit stopped before authentication.

Exact blocker and owner action ​

Missing capability: an isolated, labeled sandbox counterpart of the owner-confirmed BloxClips Whop business balance, with a sandbox Account API key, expected business/ledger origin IDs, funded/test balance, valid test recipient, transfer permission/capability, and webhook endpoint/secret.

Owner actions:

  1. Ask Whop to confirm whether Current API ledger transfers to user_… are implemented in sandbox and enabled for the BloxClips sandbox account.
  2. In Whop's sandbox dashboard, create or identify the BloxClips sandbox business balance, a non-production Account API key with only required transfer/read scopes, its sandbox biz_…/ldgr_… origin, and a consenting sandbox user recipient. Do not substitute a creator balance or an unrelated test business as the debit source.
  3. Configure secrets outside source with unambiguous names such as WHOP_PAYOUT_ENVIRONMENT=sandbox, WHOP_PAYOUT_API_BASE_URL, WHOP_PAYOUT_API_KEY, WHOP_PAYOUT_ORIGIN_ID, and WHOP_PAYOUT_WEBHOOK_SECRET. The later client must refuse to run the validator unless environment is exactly sandbox and the hostname is sandbox-api.whop.com.
  4. Expose an isolated HTTPS webhook receiver or use Whop's documented test-delivery facility; do not reuse the production webhook endpoint/secret.
  5. Record dashboard evidence of key account, permissions, balance type, payments approval, reserve, and recipient provenance without copying secrets into tickets/docs.

Smallest next test ​

Before creating any transfer, run a disposable read-only validator that:

  1. asserts sandbox environment and host;
  2. calls Current API account retrieval with reserved ID me (SDK accounts.me()) to identify the account represented by the key;
  3. compares that returned account with the expected configured sandbox origin;
  4. records the Current Account capabilities.transfer state and available, pending, in_transit, and reserve balance breakdown, then retrieves the backing ledger by returned biz_… to record ldgr_…, payments approval, and transfer fee;
  5. lists/validates the intended sandbox recipient through an officially supported origin-scoped endpoint.

Stop on any mismatch. Only after a human reviews this read-only evidence should the validator permit the minimum representable sandbox ledger credit.

Required validation sequence and pass criteria ​

This is a test protocol, not a claim that the operations work.

Test 1 — credential/account identity ​

Setup: sandbox-only host/key plus expected origin ID.
Pass: accounts.me() identifies exactly the expected sandbox biz_…; API date is pinned; no production hostname or origin appears.
Fail/stop: identity cannot be retrieved, differs, or permission is excessive/unknown.

Test 2 — spendable origin balance ​

Setup: inspect the Current Account balance/capability response, then retrieve its origin ledger/account by the returned biz_….
Pass: capabilities.transfer is active; currency and available balance cover the test amount plus documented fee; pending/in-transit/reserve, backing ldgr_…, and payments approval are captured separately.
Fail/stop: only a total balance is observable, approval is not eligible, or reserves/fees make availability uncertain.

Test 3 — recipient proof ​

Setup: a consenting sandbox creator signs into the supported Whop identity flow; server obtains a user_… subject.
Pass: origin-scoped recipient validation returns the same user and a destination ledger/balance; test records how ownership/consent was proven.
Fail/stop: recipient is guessed from email/title, is a chat-provisioned identity only, is duplicated locally, or cannot be validated.

Test 4 — minimum ledger credit ​

Setup: create one local disposable operation UUID; use it unchanged as header Idempotency-Key, body idempotence_key, and opaque metadata. Request type=ledger, currency=usd, exact sandbox origin/destination, and minimum safe test amount.
Pass: response is a transfer with a ctt_… ID, exact amount/currency/origin/destination, and documented status; origin and creator sandbox balance deltas reconcile including fee.
Fail/stop: response is a wallet send/claim link, destination differs, transfer is forbidden, or balances cannot be reconciled.

Test 5 — idempotency ​

Setup: repeat the byte-equivalent request using the exact same header and body keys.
Pass: response references the original transfer, replay evidence is observed where applicable, and balances show only one movement. Then send the same header key with a deliberately different harmless test body and verify a 400 without movement.
Do not test: key expiry by resending after 24 hours unless Whop provides an isolated resettable fixture; doing so could intentionally create a second transfer.

Test 6 — webhook ​

Setup: sandbox subscription pinned to the same API date for created/completed/failed transfer events.
Pass: raw signature verification succeeds; event ID inserts once; duplicate delivery is acknowledged without a second state change; timestamp replay and tampered body are rejected; event account/object match the transfer.
Additional pass: out-of-order handling triggers retrieve and converges to current provider state.

Test 7 — retrieval/list reconciliation ​

Setup: retrieve ctt_… and list narrowly by origin/destination/status/time.
Pass: both surfaces identify the same operation using ID plus metadata, amount, currency, and parties.
Fail: only amount/time matching is possible.

Test 8 — one safe failure ​

Prefer a Whop-provided sandbox failure fixture or a zero-side-effect invalid recipient/insufficient-permission request.
Pass: documented 4xx/failure code is captured, no balances move, no transfer is later reported succeeded, and retry classification is verified.
Do not simulate: production insufficiency, real KYC failure, real recipient, intentional network cut after a production create, or any failure that may move real funds.

Test 9 — uncertain timeout/crash harness ​

Use a local fake transport or Whop-approved sandbox proxy to drop the response after the provider accepts the request.
Pass: local state becomes UNKNOWN, the system retrieves/replays the same semantic operation, and exactly one provider transfer/balance movement exists. This can prove BloxClips behavior even if Whop sandbox cannot force a real timeout.

Evidence to preserve ​

For each test, save a redacted evidence bundle outside Git containing:

  • timestamp, operator, environment/host, API version date, SDK version;
  • local operation and test-case IDs;
  • origin/destination ID suffixes or approved full IDs in restricted storage;
  • request hash and idempotency key hash, never the API key;
  • HTTP status, provider object ID/status, replay header, failure code;
  • balance before/after and fee, with secrets/PII redacted;
  • webhook ID/type/timestamp/API date and signature-verification result;
  • retrieve/list result hashes and final reconciliation conclusion.

The checked-in summary should report pass/fail and sanitized identifiers only. Never commit API keys, webhook secrets, authorization headers, raw signatures, external payout methods, or personal data.

What sandbox cannot establish ​

Even a full pass cannot prove production underwriting/approval, geographic and currency availability, real settlement latency, production fees/reserves/velocity limits, recipient compliance/KYC, creator external withdrawal success, or support behavior during provider incidents. Production remains gated by written Whop confirmation and a tightly limited canary using explicitly authorized non-real/test facilities; this audit authorizes no real-money test.