Skip to Content
Build an integrationFinancial integration safety

Developer reference

Financial integration safety

Preserve user intent, financial context and retry identity when an integration can change money.

Financial writes have consequences beyond updating a label. Start with reads, then add writes only for a clear user instruction.

Before sending a command

Confirm the intended user, owned record IDs, amount, currency and date. Choose the command that matches the real event: transfer, purchase, repayment, income and borrowing are different meanings.

Use minimum scopes and a finite timeout. Preserve the endpoint’s idempotency key and original payload for supported money commands.

What an integration must not infer

A due plan does not prove payment. An income source does not prove a receipt. A reference quote does not prove a bank execution rate. Provider credentials do not prove a live owned session until verified.

For a fictional EGP 500 transfer, preserve the two accounts and same-currency intent rather than representing it as income in one account and spending in the other.

Recover without duplication

After a timeout, inspect the existing operation and retry the same intent according to idempotency. Continue an import’s existing job instead of uploading and recording it again. Changing source interpretation requires new review and consent.

Corrections should preserve the explanation of changed money. Do not quietly replace an unrelated movement to force a desired balance.

Protect credentials and data

Keep tokens and financial payloads out of logs. Revoke exposed credentials. Browser logout and token revocation are separate operations. Read destructive controls before offering deletion or undo.