A user chooses a service and pays. That is the visible part. Inside the organisation, someone still needs to know whether the payment matches the right request, how to handle a cancellation and how to explain a discrepancy.
Before pricing payments, walk through the complete process with service staff and the team responsible for reconciliation.
Connect the payment to the service
What exactly is the user buying? When is the order created, and when is it confirmed? Is an event place held before payment, and for how long?
Agree which identifier links the payment, request and correspondence. Staff should be able to find a case without guessing which purchase a transaction or user message concerns.
Walk through awkward situations
Someone abandons payment, returns later, tries again or sees an unclear status. What should they see, and what can staff check? Do not base the entire process only on the user returning to the site after paying; agree with the supplier how the provider's payment status will be confirmed.
Describe cancellation and refund handling separately, using your organisation's agreed rules. Establish whether staff act in your system or the payment provider's interface, and where the result appears.
Separate implementation from operation
Ask for separate scope items covering the provider connection, administration changes, messages, testing and staff reports. Include the chosen provider's fees in operating costs rather than treating them as part of the development price.
For acceptance, prepare a successful transaction and the agreed exceptions in a test environment. Check the customer-facing messages and whether staff can understand and resolve the resulting case. They will be answering questions after launch, so their part of the journey needs to be included in the work you buy.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database