Payments, integrations & automation
Write an integration brief before connecting systems
Describe ownership, events and failure handling so an integration solves a workflow problem without creating hidden exceptions.
2 minute read · Practical guide
The key decision: Define what happens when a message is late, repeated or rejected.
More on Payments, integrations & automationName the business event
Begin with a concrete trigger such as an accepted order, a stock adjustment or an approved refund. Identify the source record and the destination action. “Connect the store to the ERP” is too broad to decide which events, fields and business rules belong in the first release.
Choose an owner for each field
Decide which system controls product identifiers, sellable stock, prices and order status. Record the mapping and the circumstances in which a value can change. If two systems can edit the same field, define how a conflict is resolved before enabling automatic updates.
Specify the failure behaviour
List the cases a normal demo misses: the destination is unavailable, a required field is missing, the same event arrives twice, or events arrive out of order. Agree retry limits, duplicate detection and a human exception queue. A successful HTTP response alone may not prove the business record is correct.
Keep access and data requirements narrow
Request only the permissions and fields needed for the agreed workflow. Exchange credentials through an approved secure method, never an enquiry form. Define what diagnostic logs may contain and who can review them. Use synthetic or suitably protected test data for acceptance.
Agree a release and recovery plan
Start with a representative event set, compare source and destination records and keep the original workflow available where feasible. Name the owner for monitoring and failed-event resolution. Document how to pause the connection and reconcile missed work if the release needs to be rolled back.