Keep the reference useful across the connection.

A provider result must update the intended order

For a Nigerian merchant using a supported payment provider, the useful integration question is what a verified transaction means for the business record. A returned page, a successful API call and a successful payment are different pieces of information.

Paystack's verification documentation illustrates this distinction: the response describing the API call is separate from the transaction result within its data. We can connect a chosen provider and an order system around the actual documented fields. This example does not establish merchant eligibility or an approved account.

Match before changing fulfilment

Agree which reference identifies the order and which verified amount, currency and state permit the next action. A later result must reach the same intended record. An uncertain or inconsistent result should leave a visible review task rather than release a product automatically.

Handle both delivery paths

A provider notification and a customer returning to the site may concern the same transaction. Test them in either order and confirm the business action happens only as intended. Include a delayed result and an amount that does not match the order.

The handover names the client-owned accounts, investigation view and route to pause or repair the flow. Credentials stay outside public code. Acceptance checks the receiving business record as well as the API response; live transactions are a distinct planned test.

Reference: Paystack payment verification. Tell us which systems must share a payment result.