Payments & DBPay
Integrated Payments in Distributor Workflows
Taking a payment is one task.
Knowing what that payment belongs to is another.
A customer might pay an invoice, check out through a company store or respond to a payment link. Once the transaction succeeds, the distributor still needs to know who paid, what they paid for and whether the systems handling the customer account reflect the same result.
The card transaction can be complete while the distributor's work is not.
Processing the payment is only part of the job
Consider an invoice paid through a payment tool that sits outside the distributor's ERP.
The payment is approved. The money moves.
But if the ERP does not receive that information, someone still has to find the customer, record the receipt and apply it to the right invoice.
There are perfectly valid reasons to process a payment outside the ERP. What the example shows is that processing a payment and connecting it to the financial workflow are separate jobs.
Integration determines how much work remains after the payment succeeds.
Starting from the invoice gives the payment context
A payment processor needs to know enough to complete the transaction.
The distributor needs to know more.
Which customer is paying? Which invoice does the payment belong to? Was the full amount paid? Has the customer's balance changed?
This is where invoice-oriented payment workflows are useful.
DBPay supports invoice-oriented Pay by Link, allowing a customer to pay through a secure link associated with the invoice rather than requiring the distributor to collect card information separately.
The payment starts with something the business already recognizes.
That makes it easier to preserve the relationship between the money received and the transaction it is meant to settle.
Commerce starts with a different kind of transaction
A company-store payment happens earlier in the process.
The customer is already selecting products, entering order information and completing checkout. There is an order behind the payment from the beginning.
DBPay is integrated into Commerce payment workflows, which means payment can be part of the customer-ordering experience rather than a separate collections step.
That context can include more than the total amount.
Current Commerce functionality can transmit Level 3 line-item information through DBPay, including item amount, product title, item ID and quantity. For eligible corporate and purchasing cards, providing that additional information may qualify a transaction for lower interchange rates.
That qualification matters. Level 3 data does not guarantee lower processing costs for every transaction.
For more on the ordering environment around those payments, see B2B Ecommerce for Print & Promo Distributors.
Getting paid and seeing the deposit are different views of the same activity
A customer can receive an approval immediately, while the merchant sees the funds later according to processing and banking schedules.
Deposits can also contain multiple transactions.
So finance may see one amount arrive at the bank while customer-facing teams have been working with several individual payments.
That is where reporting and reconciliation become useful.
The business needs to be able to move from the deposit back to the transactions that produced it without guessing which payments have been grouped together.
Refunds and chargebacks add another layer. Money associated with an earlier transaction can move in the opposite direction days or weeks later.
Those events do not change the original order. They change what happened financially after it.
Someone responsible for the customer account needs to be able to understand that difference.
Reporting should help explain what happened
Payment reporting has a practical job.
- A deposit does not match a single invoice. Why?
- A customer says they paid. Did the transaction settle?
- Money was deducted from a deposit. Was there a refund or chargeback?
- A transaction succeeded, but receivables still shows the invoice as open. Does somebody need to record or apply the payment?
ERP and accounting reports answer different questions.
The useful connection is being able to move between them without losing track of which customer transaction the money belongs to.
For a deeper look at how information moves between operational and financial systems, see Connecting ERP to Your Accounting System.
Manual work usually appears at the boundaries
A payment process can work exactly as designed and still leave somebody with administrative work afterward.
The transaction succeeds, but someone records it again.
A deposit arrives, but finance has to work backward to identify the transactions inside it.
A refund is processed, but another team is still looking at the original customer balance.
These are not necessarily payment-processing failures.
They are signs that the boundary between payments and the surrounding business process deserves attention.
For distributors evaluating payment workflows, the more useful question is: after the customer pays, where does that information need to go next?
DBPay supports payment processing across Commerce and distributor workflows, including Commerce payments and invoice-oriented Pay by Link.
What matters afterward is whether the payment result reaches the people and systems responsible for the customer transaction.