DNA Pay: connecting a payment request to the ERP receipt

A payment request invites the customer to pay; it is not yet a receipt. Payment links support remote collection, while Tap to Phone supports an in-person collection using a paired compatible phone. Gateway approval and successful recording in the ERP are separate stages that must both be checked.

DNA's gateway configuration connects the collection method, clearing account and devices. Payment gateway receipts are later settled to the bank through Gateway Payouts. The company's enabled integration and paired-device setup determine which options are available. Keep pairing credentials and cashier identifiers out of training examples.

Choosing the collection method

A payment link suits a customer paying remotely. Tap to Phone suits an in-person payment collected through the supported paired Android device arrangement. Both methods begin with a defined collection request and should remain connected to the invoice being paid.

The request amount matters when partial collection is allowed. Asking for part of an outstanding invoice should leave the uncollected remainder visible. Creating a request for the full balance when another request or payment already exists can create confusion unless the current position is understood.

A partial collection

An invoice has 1,000 outstanding and the customer is asked to pay 400. After the successful payment is recorded and applied, the remaining balance should be 600. A still-open request for 400 must not be counted as received cash, and the later provider bank deposit is not another customer sale.

The request itself is an invitation to pay. Gateway processing and approval describe the provider's progress. Recording in DNA establishes the ERP receipt. These stages should remain distinguishable because a successful provider transaction and a successfully recorded ERP transaction are separate pieces of evidence.

The receipt and the later bank deposit

DNA's customer-payment view distinguishes gateway receipts and displays their provider information and receiving account. Provider-confirmed details are controlled because they represent an external payment event rather than a freely editable estimate.

The Gateway Payouts workflow represents the provider's later bank settlement against its clearing relationship. It is not another customer sale or a second receipt from the customer for the same invoice. Fees and payout timing can explain why the bank deposit differs from the gross amount collected from customers.

Open and replaced requests

An open request needs to be understood alongside payments already completed. Replacing an open request and recording a payment are different operations. The request panel can request cancellation and refresh its status; if payment has already completed, the actual returned status and receipt remain the evidence. The system's recorded payment and customer balance remain the relevant evidence.

The invoice's online-payment information helps explain request references, methods, amounts, and status history. This is useful when the customer reports payment but the finance team needs to identify the corresponding ERP receipt.

Device and integration readiness

Tap to Phone depends on the enabled gateway, compatible device requirements, and pairing configuration. The presence of a smartphone alone does not make it a payment terminal. Those requirements belong to the operational setup, while the sales lesson focuses on the collection relationship.

The business outcome is a traceable chain from invoice to request, provider result, ERP receipt, and eventual bank settlement. Each stage answers a different question about the same collection.