Forcing outcomes

Nothing here is a special endpoint or a flag. The outcome follows from a value you send — an identifier on the business, an amount on a payment — so you exercise a rejection by making the same call you always make, with a different number in it. Every value is in Test value tables. This page is what each outcome is for.

​

Approval

Send any business identifier that is not one of the special values and the application is accepted normally, then activates. This is the path you build against.

​

Rejection

Two different failures, and they are worth testing separately because your handling of them differs: Refused outright. The business cannot be onboarded, and sending it again changes nothing. Your product has to tell the customer that this is final rather than offering a retry. Refused on the data. Something in what you sent is wrong or missing. This one is worth retrying, once your customer has supplied the correction.

​

Rejection after acceptance

The most useful one, and the one most integrations skip: the application is accepted, and is rejected later on review. This is the shape that breaks flows built on the happy path, because your code has already told the customer they are onboarded by the time the decision arrives. If you test one failure, test this one.

​

A payment that is refused after it was accepted

Send a payout whose amount ends in a particular pair of decimals and the call is accepted, then a later callback fails it. Use it to prove your integration does not treat acceptance as delivery — a refusal really can arrive after the payment was taken, which is the thing Payout warns about, exercised rather than read.

​

A deposit that is returned

A deposit of a particular amount comes back as returned instead of crediting. Use it to check that your reconciliation does not assume money that arrived stays.

​

A hold, and what it resolves to

A compliance check can hold a movement before it settles, and the sandbox lets you choose how it ends: one pair of cents holds it and then approves, another holds it and then rejects. They resolve on their own — you do not need anyone at Kira to release one. Use them together rather than separately: the interesting bug is not in either ending, it is in the code that runs while the movement is paused and assumes it will resume. A held deposit also blocks every payout from that account while it lasts, so a test that leaves one held will look like a broken payout later.