Testing Connect

Connect is on in test mode for every account from sign-up. A test key creates test connected accounts, and nothing real moves. This page covers Connect’s part of Testing; everything else there also works as each account, with Tuppence-Account.

1. CreatePOST /v1/accounts
2. Verify…/test_helpers/accounts/{id}/verify
3. Pay as itpm_card_bypassPending
4. Advance…/test_helpers/clock/advance

A test connected account

A test account starts like a real one (requirements due, charges_enabled: false), so you can build onboarding. To skip straight to payments, verify it:

curl

curl -X POST https://api.tuppence.ai/v1/test_helpers/accounts/acct_1…/verify \
  -H "Authorization: Bearer $TUPPENCE_SECRET_KEY"

Node

await tuppence.request("POST", "/v1/test_helpers/accounts/acct_1…/verify");

Python

tuppence.request("POST", "/v1/test_helpers/accounts/acct_1…/verify")

1. It sends the test values within the request.
2. The account stays at pending_verification for about half a minute (allow two).
3. Payments and payouts turn on, with a test bank account. Your Connect endpoint hears account.updated with charges_enabled: true.

Wait for that (or poll the account’s charges_enabled) before paying as it. Until then, a payment is 403 onboarding_incomplete.

Build the trouble screens by setting the account’s requirements. Anything past due turns charges and payouts off, and your Connect endpoint hears account.updated.

curl

curl https://api.tuppence.ai/v1/test_helpers/accounts/acct_1…/requirements \
  -H "Authorization: Bearer $TUPPENCE_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"past_due": ["individual.dob.day"], "disabled_reason": "requirements.past_due"}'

Node

await tuppence.request("POST", "/v1/test_helpers/accounts/acct_1…/requirements", {
  body: { past_due: ["individual.dob.day"], disabled_reason: "requirements.past_due" },
});

Python

tuppence.request(
    "POST",
    "/v1/test_helpers/accounts/acct_1…/requirements",
    body={"past_due": ["individual.dob.day"], "disabled_reason": "requirements.past_due"},
)

The fields are currently_due, past_due, pending_verification, disabled_reason, current_deadline.

Test values

What …/verify sends, and what passes verification when you onboard through the API:

Field	Value
Date of birth	1901-01-01 (any other date stays unverified)
Address line 1	address_full_match
Bank account	Sort code 10-88-00, account 00012345Routing number 110000000, account 000123456789The test IBAN of the account’s country as account_number, with no routing number: DE89370400440532013000 in Germany, FR1420041010050500013M02606 in France
SSN (US accounts)	Last four 0000; full number 000000000
Failing bank account	Sort code 108800, account 11111116Routing number 110000000, account 000111111116IBAN DE62370400440532013001 (Germany): the next payout fails no_account and the money returns to the balance

Rehearse the hosted page

Hosted onboarding works in test mode as it does live: it asks for what’s due, and the account updates as each form is sent.

• Identity check: practice buttons for a check that passes, or one that fails and says why.
• Bank account: use the test numbers above, on the page or as external_account through the API. A bank token (btok_…) is refused in test mode, as in live.

Move its money

To	Do
Have money available at once	Pay as the account with pm_card_bypassPending on POST /v1/payments/{id}/confirm. The account can pay out its money at once and you can transfer your fee. Other test cards stay pending for the card’s clearing days, and no API releases them sooner
See a payout	It settles by itself, by the bank account’s number
See a payout bounce	Add the failing bank account (above) with POST /v1/accounts/{id}/external_accounts
Take an account below zero	As the account, POST /v1/test_helpers/payments/{id}/dispute, then …/disputes/{id}/close (won or lost). A loss takes it below zero: watch its losses covered
Skip days	POST /v1/test_helpers/clock/advance (below). It moves our settlement days, not the card’s pending period

A clock for each account

Your platform and each connected account have their own test clock. POST /v1/test_helpers/clock/advance with {"days": 8} moves the clock of the account the request acts as, and runs whatever those days would have run:

Clock	Runs
Your platform’s	The daily sweep of your Connect balance. Not your own payouts, which run on their own schedule
A connected account’s (Tuppence-Account)	Its payouts on its schedule, and the losses ladder if it’s below zero

Moving one account’s clock never moves another’s.

Hear it without a server

A webhook inbox is a URL that keeps what it receives. Point a Connect endpoint ("connect": true) at one and read back your accounts’ events with their account. The whole flow does this.

In CI

Tuppence’s CI runs the Connect demo end to end on every change, and both SDKs run the same script against staging: accounts created, verified, paid, refunded, swept, transferred and paid out. Your tests can do the same with a test key and these helpers.

Next

• The whole flow in one script
• Testing: cards, clocks and inboxes for every account