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.