​

Understand transaction states

A transaction is the commercial and operational record of one delivery to one buyer. It links:

• the person and interest
• the channel and buyer
• delivery time and method
• buyer price, supplier cost, and margin
• confirmation, rejection, Storno, and payout events

​

Typical lifecycle

The exact states available depend on the buyer integration and commercial process.

​

What each outcome means

​

Delivered

Airlead sent the interest and created a transaction. This does not necessarily mean the buyer has accepted it commercially.

​

Confirmed or acknowledged

The buyer reports that it accepted the delivery. Use the transaction history to see who or which integration applied the update.

​

Rejected

The buyer reports that it did not accept the delivery. Review the reason and confirm whether it is billable or may be delivered elsewhere.

​

Cancelled / Storno

A previous delivery is cancelled with a structured reason. Permissions, timing, and partnership terms determine who may submit it and what commercial effect it has.

​

Payout pending and paid out

These states track the buyer-side payment lifecycle. They are not a substitute for reviewing the final settlement document.

​

A transaction can show several statuses

Do not treat every status column as the same state: For example, a webhook can be accepted technically while the buyer later rejects the lead commercially, or a confirmed transaction can still wait for payout and settlement. Workspace administrators can configure the visible workflow statuses under Settings → Status. Integrations should use the documented lifecycle contract rather than assuming a custom display label has API meaning.

​

Investigate a transaction

1. Open the transaction.
2. Verify buyer, interest, product, and delivery method.
3. Compare buyer price, supplier cost, and margin.
4. Review every status event and reason.
5. Check whether the update came from an operator or partner integration.
6. Compare it with the relevant settlement period.

​

Common questions

​

Can one interest have several transactions?

Yes, when Multi delivery is permitted or when valid redelivery/resell behavior creates another buyer delivery. Each buyer delivery should have its own transaction.

​

Why does a transaction exist before confirmation?

The transaction begins when Airlead delivers the interest. Confirmation is a later lifecycle event.

​

Can a repeated callback create the same status twice?

Partner lifecycle endpoints are designed to recognize already-applied transitions where supported. Integrations should still retry with the same transaction reference and treat an already-applied response as success.

​

Why does settlement not match the current transaction count?

Check the settlement period, billable statuses, Storno timing, and whether values changed after the period was prepared. Next: Plans and settlements · Partner lifecycle integration