Skip to main content
Connect is tested with your sk_test_ keys, on the same endpoints as production.

​
The environment is inherited, never chosen

An sk_test_ key only creates test vendors, and can only target them. The environment of a connected account is inherited from the key that created it: there is no field to choose it.Targeting a live vendor with a test key (or the reverse) returns 401, on every Connect route. This is not a key bug: it is the isolation barrier.
This is the first symptom to recognise: a 401 on a vendor you have just created almost always means you changed keys between the two calls.

​
1. Activate Connect on your test account

Activation happens in your dashboard, under Connect, with your test account.
The mode is immutable, including in test. You will not be able to switch your test account from marketplace to platform to compare the two cascades. To test both modes you need two separate merchant accounts.
Then check that your integration really reads the mode:

​
2. Create test vendors

Nothing distinguishes the creation of a test vendor: same fields, same required Idempotency-Key.
Create at least two, and keep one you never verify: it is the only way to exercise the verification-related refusals (403 E_VERIFICATION_REQUIRED, 422 E_CONNECT_VENDOR_PAYOUT_METHOD_UNAVAILABLE).
Also create a vendor under a second merchant account. It is the only way to check that your code handles the 403 of a vendor that is not yours, a case you will meet in production as soon as an identifier slips from one tenant to another.

​
3. Verification is not instant in test

Do not count on automatic approval in test. You will get the link, the vendor will be able to submit their documents and their payout destination, but the file goes through a review: its move to approved is neither immediate nor guaranteed.To obtain an approved test vendor (needed to exercise withdrawals), contact support@yabetoopay.com.
What you can verify without approval:
  • link generation and expiry (expires_at);
  • the fact that regenerating the link resumes the session instead of opening a second one;
  • the 422 refusals on country and kycLevel;
  • that funds do accumulate while no withdrawal is possible.

​
4. Test collection and the cascade

The split is computed at capture. Use the usual test numbers to drive the payment outcome. See Test your integration.
1

Create the intent with the Connect fields

2

Confirm with a test number that succeeds

The split only happens on a successful capture.
3

Read the vendor's balances back

You should see the vendor net in pending_balance, and balance at zero.
Check conservation, not just the HTTP code. On every capture, vendor net + your net + Yabetoo fees must equal the gross exactly. That is the assertion that catches a mode or unit error; a 201 proves nothing.

​
Exercising the commission refusals

The too_low refusal does not depend on the amount: a rate under the floor fails at 100 XAF just as it does at 1,000,000. There is no point looking for an amount that triggers it.

​
5. The availability delay

This is the main difficulty of end-to-end testing. A vendor’s funds land in pending_balance and only become withdrawable after the availability delay, 7 days by default. There is no test clock and no endpoint to force maturation.To test the full chain in one session, ask support for a shortened delay on your test environment.
In the meantime, you can verify:
  • that next_maturity_at carries the expected date;
  • that available_at is set and matured_at is null on the transaction;
  • that a withdrawal against a still-pending balance really returns 422 E_CONNECT_VENDOR_EMPTY_BALANCE, and not a generic error.

​
6. Test deferred mode without waiting

Deferred mode can be exercised without a real collection: all you need is a balance on your own merchant wallet. It is the fastest way to verify:
  • the 1% surcharge and the meaning of amount in the response;
  • a partial then a full reversal, and the reversed_total running sum;
  • the 422 connect.reversal_exceeds_remaining when you exceed the remainder;
  • the 402 on reversal when the vendor cannot return the funds.

​
7. Test idempotency for real

Replay every money call with the same Idempotency-Key and check that no second operation was created (by reading the balances back, not by reading the HTTP code).Also check the opposite case: the same key on two different vendors must produce two operations. An implementation that deduplicates there would only pay one vendor out of two.

​
What cannot be tested

​
Going to production

1

Activate Connect with your live key

Activation is per account and per environment: activating in test does not activate in production.
2

Recreate your vendors

A test vendor does not exist in production. No migration is possible, and their verification has to be done again.
3

Rewire your webhooks

Check that you subscribe to the bare names (connect.transfer.created), and that your routing does not assume accountId is your own account.
4

Check how you handle the 402

It is the refusal you will probably never see in test, and the one that costs the most in production. Subscribe to connect.refund.blocked_insufficient_funds.