Skip to main content
Requires the reservation Component and Endpoint from step 2, plus an authorized test integration.

Configure durable settlement

Create a Job template for the provider call. The Job reads the transaction by transactionId, verifies that its state is still eligible, calls the provider with a provider-side idempotency key, and records only the safe provider reference. Jobs can run much longer than Endpoints, but they are still bounded. Instance policy can grant up to 59 minutes of execution time and 4 GiB of memory. Design larger work as checkpoints or multiple Jobs rather than assuming an unbounded process, and reserve only the memory the workload actually needs.
A remote timeout is ambiguous: the provider might have completed the operation before the connection failed. Query by the provider idempotency/correlation key before retrying the side effect.

Settlement worker: Secret, HTTP egress, and Storage evidence

Before activating the template, create PAYMENTS_API_KEY under Secrets, grant the Job service account access to it, configure the provider URL as non-secret Component configuration, and pre-create payments/settlement-receipts as a restricted Storage path for finance/audit groups. The Component still verifies effective restriction at runtime because storage.ensureFolderPath() does not mutate ACLs on folders that already exist. The settlement Component binds the credential at the HTTP boundary, sends a JSON request to the provider, updates the ledger, and writes a restricted receipt artifact. It never returns or logs the resolved API key. The originating Endpoint operation and the Job operation remain separate but linked.
Never log provider.request, request headers, the Secret value, or an unrestricted provider response. api.httpCall() returns diagnostic request data for runtime use; application logs should contain only allowlisted identifiers, status, and timing.
If the HTTP connection times out, query the provider with the same transactionId idempotency key before sending another settlement. If Storage writing fails after provider success, a retry can reconstruct the deterministic receipt from the settled ledger record without repeating the provider effect. Continue with first production workflow. Previous: step 2. Next: step 4.
Last modified on November 8, 2026