Connecting Payments to Your Sales and Job Records

Decide what the payment belongs to

• The business recordThe sale, invoice, order or job that explains why the customer is paying.
• The provider’s transactionThe payment record and reference used to confirm what happened to the money.

Keep those references connected from the start. An amount and customer name may not be enough when the same customer makes several payments of the same size.

Identify whether this is full payment, a deposit or one instalment. That determines what staff need to see afterward and which amount remains to be collected.

Use the confirmed result

Opening a payment page or pressing a button does not confirm that the customer paid. The software needs the payment provider’s result before recording the corresponding outcome.

Stripe’s payment-status documentation distinguishes payments that need another action, are still processing or have succeeded. Other providers have their own states; ask the developer to explain how those states will appear to staff and customers.

Use plain messages for unresolved results. Staff should know whether to wait, check the provider or ask the customer to try again after a confirmed failure.

Handle repeated actions without duplicating the result

A customer can click twice or reopen a payment link. A connection can also receive the same payment update more than once. Plan for those ordinary situations.

Stripe’s guidance on payment notifications explains that notifications can be retried and duplicated. Ask for the integration to recognize an update it has already handled, so another notification does not create another receipt or repeat the next business action.

If a result is unknown, check the existing attempt before creating another charge. Make it possible for staff to investigate using the saved payment reference.

Decide what happens after payment

Payment may allow an order to proceed, confirm a booking or satisfy a deposit requirement. Define that next step rather than using paid as a substitute for every other job status.

A paid job may still need materials, scheduling or delivery. If the next action fails, staff need to see that the payment succeeded but the work still needs attention.

Keep receipts and customer messages linked to the confirmed transaction. Check that retrying an update does not repeatedly send the same message.

Keep later changes connected

A refund, correction or payment dispute can affect a transaction after the original success. Keep later events associated with the original payment and business record.

Decide which program staff use for each action. If a refund is made directly through the provider, the connected system still needs an appropriate way to learn about it.

The guide to deposits, partial payments and refunds explains the information staff need when an account involves more than one payment or a later return of money.

Check the connection with real working situations

Use the provider’s supported test process to try a successful payment, a decline, a delayed result and a repeated submission. Follow each one into the customer and job records.

Ask what information the connection can access and who can issue refunds or change settings. Keep card collection within the provider’s supported payment tools.

Compare an available integration with any custom connection you need. Include setup, fees, support and the way staff investigate a mismatch between systems.

Your next step

Choose one type of payment and write down what it pays for, how success is confirmed and what should happen next. Include a delayed result so the unresolved case is planned as clearly as the successful one.