Worked deposit example
A member deposits ₦5,000 with operation C-101. The app receives a provider success event and queues a core posting. The core rejects the posting because the account is closed. Expected: the app shows funds received with allocation under review, the available savings balance stays unchanged, and an exception links C-101 to the provider receipt and core rejection. After an authorized resolution, post a new adjustment or refund with its own ID. Never edit the rejected record into a success. This is a synthetic case; the exact customer notice depends on the cooperative contract.
Name the owner of each fact
Put the app, core, and bank statement in a three-column map. For member status and balance, choose the system of record. Document what happens if a posting succeeds in one system and fails in another. A retry needs the original operation reference across all three.
Checks to run
- Map which system owns member identity, account status, balance, and transaction status.
- Reject a core response that changes the member ID or account ID attached to the original request.
- Reconcile app requests, core postings, and bank settlement; send unmatched entries to a named review queue.
Reconciliation cases
Run a posted deposit missing from the core, a core posting with no bank settlement, and a duplicated import line. Each should open a named exception. Mark the customer view pending until the system of record confirms the final balance. If a correction is needed, write a new adjustment; keep the original entry intact.
Check that member IDs cannot be swapped when the core returns a response. A technical success code does not prove the response belongs to the original member request.
One more boundary test
Test a member merge or account closure during import. A deposit file may carry an account ID that was valid when the payment started but closed before the core posts it. The integration must not redirect that money to a new member based on a fuzzy name match. Hold it as an exception and check the exact account history. Also test a core schema change that adds a required field. A rejected file should alert an owner; a silent empty import can make a missing deposit look like no activity.
Reconcile a core mismatch
Start with a member balance of ₦12,000 in the core and the app. Post a ₦2,000 withdrawal in the core, then hold the reply to the app. The app must show a pending request or refresh from the core; it must not create a second withdrawal to make its local balance match. Compare member ID, operation ID, amount, core posting time, and app receipt. If the core shows ₦10,000 while the app shows ₦12,000, open an exception with both records. Do not repair the gap by changing one balance field. PostgreSQL documents the transaction isolation choices that matter when local writes run at the same time.
Keep received funds distinct from posted savings
For C-101, provider success establishes received funds under the provider contract, while a rejected core posting means those funds are not allocated to available member savings. Use separate states such as funds received and allocation under review. Do not label the provider payment failed merely because the core import failed; that label invites another deposit. Keep the received amount in a reconciliation or suspense record tied to C-101. An approved refund or corrected posting resolves it as a new linked action. Test duplicate core acknowledgments and duplicate provider events independently. Closing the exception requires one matched money outcome, not a green import job alone.
Primary sources
Next step
Take one recent failed core import and trace its app, core, and settlement records through the exception queue. Read the related guide. For a review of your own system, request a security review.