pipelogiqPayment reconciliation
Keep a successful payment visible when a downstream integration needs another attempt.
This implementation pattern mirrors the deposit example on the home page. It uses a fictional provider and does not initiate real payments. Pipelogiq supplies execution coordination; your handlers supply provider and wallet integrations.
The workflow
| Stage | Handler responsibility | Useful result |
|---|---|---|
| Validate event | Validate the provider event and stable reference | Event accepted, or terminal validation failure |
| Confirm payment | Read the existing provider payment | Confirmed, pending, or rejected |
| Credit wallet | Apply the confirmed credit once in your ledger | Existing or newly recorded transaction reference |
| Sync CRM | Update the customer profile using the same operation key | Profile synchronized, or transient error |
| Send receipt | Deliver a deduplicated notification | Delivery reference |
Create the pipeline with an application-scoped idempotency key derived from the provider event. Within each side-effecting handler, use a separate stable business-action key. A pipeline creation key does not automatically deduplicate wallet credits or emails.
Put the retry boundary around the failed operation
If the wallet update completes and CRM synchronization fails, leave the completed stages intact. A retry should call the CRM handler again with the same business reference.
Before an external retry, query the provider when the previous outcome is unknown. An HTTP timeout may happen after the provider committed the operation. Avoid using an execution ID as the external deduplication key because it changes across attempts.
The reliability guide explains retry classification and reruns. Both SDK recipes include native error and context examples:
Give support the right context
Include the operation ID, provider reference, current confirmed outcome, and next action. Keep card numbers, access tokens, full identity documents, and raw financial payloads out of general support context.
A useful answer is: “Your deposit is confirmed. Your wallet has been credited. The customer-profile update is delayed and will be retried.” This answer is valid only after your own ledger and provider integrations confirm those facts.
The home-page demo formats a friendly summary from fictional data. In your application, expose meaningful stage output and context; the dashboard does not automatically infer a customer-service message from arbitrary logs.
Test recovery before enabling mutations
Run each test against a sandbox ledger and a provider fake:
- All stages succeed and the pipeline completes.
- CRM returns a transient error once, then succeeds. The ledger records one credit.
- The provider rejects an event. The workflow records the business rejection and does not credit the wallet.
- Submit the same event twice. The server returns the existing pipeline for the same intent.
- Simulate a timeout after the ledger commits. Reconciliation finds the existing transaction and avoids a second credit.
A passed handler unit test does not verify broker delivery or server retries. Include a real local server round trip as described in installation.
Operate the workflow
A Viewer can inspect the run within assigned applications. An Operator can use the recovery actions exposed for failed stages. Before rerunning a side effect, inspect its output and check the external system. An engineer is still needed when business logic, credentials, or an unknown external outcome cannot be resolved through the available operational controls.
See Use the dashboard for the actual controls and access management for roles.