Payment

What It Is

A payment is Accounting’s retained record of money collected for a customer. It can represent a check, cash, transfer, card capture or bank debit. Staff record money received outside Rhythm or collect it through a processor. The record identifies the customer, business unit, currency, financial destination and configured payment method. Those choices give later staff a way to understand both the receipt and the permitted treatment when money must be returned.

Collected value can settle invoice lines or remain available on the receipt. A payer can be someone other than the customer, but attribution does not itself authorize paying another customer’s bills. The current model keeps each payment tied to one customer’s invoices. A remittance groups the recording of money for several customers through separate receipts until the later single-receipt model arrives.

What It Is Not

A payment does not define the purchase; an invoice records billed charges and Commerce retains the order. Available receipt money is also distinct from customer credit. Moving money into credit produces another record with its own restrictions and applications. A refund records returning value, while a payment reversal records that collected money did not remain. A processor payout is the separate reconciliation concern of transferring collected funds to the bank.

How It Is Used

Staff record checks with the relevant reference and allocate them to the intended invoices. They can leave excess available for later use or correct a misplaced allocation while retaining the earlier entries. Hosted processor fields support phone payments without collecting card numbers into Accounting. Staff review uncertain results instead of assuming a missing response means nothing was charged. Processor events and scheduled lookup finish interrupted work, with human review available when scheduled recovery cannot establish an outcome.

Its Facets

Method and behavior. Customer-defined methods determine the appropriate offline, card or bank-debit path. The retained behavior makes later reversal choices understandable even if configuration changes.

Intent and lost answer. An intent records an external attempt before charging. Lookup asks about that attempt rather than creating another one, and exhausted uncertainty becomes work for a person.

Application and available money. Applications explain how receipt value reaches invoice lines. Value not consumed remains available, and opposing entries explain later removal from a target.

Payer. Sender attribution helps distinguish the member’s own money from an employer or another contributor. It is evidence of who paid rather than an extension of the eligible target population.

Settlement and remittance. Settlement coordinates credit and one tender for selected invoices. Remittance records one outside receipt covering several members through the current per-member split. Either can create work involving several records rather than being interchangeable with the payment itself.

Card fee. Fee-bearing invoices can add a separately billed processing cost. That fee retains its own relationship to the collected money and later return treatment.

Refund. Returning value has a request, reservation, optional approval and execution outcome. Definite failure restores value, while uncertainty continues holding it until resolved.

Reversal and dispute. A void, bounced check, bank return or chargeback explains money that did not stay. A dispute records the processor’s inquiry or chargeback and may lead to that reversal.

How It Relates

Invoices supply the debt that applications settle. Credit can take available money from the payment, and a memo can release previously applied money back to it. Customer-account views include held receipt value, while shared transaction safeguards preserve identity and history. Captures, refunds and processor reversals supply reconciliation facts without moving payout ownership into Transactions.

What It Could Become

The product should confirm the later single-receipt model and settle the partial-chargeback treatment before relying on it in design. It should decide whether free-text refund explanations may be sent to a processor. Stored instruments and portal payment experiences remain later work; their introduction should preserve the existing distinction between an attempt, a collected receipt and its applications.