Accounting Payments

This standard governs the payment records of All About Pawz, LLC: how money moves for first-party sales today, how it is designed to move for marketplace Seller sales, and how the Accounting Operator works the records day to day. Where funds sit at each stage determines whether a payment problem belongs to the Company, to a Seller, or to the payment processor, so every operator who touches payments shall understand both tracks below. Payment collection for Sellers is governed by the Selling Terms of Service; this standard states the accounting practice under it and does not restate it.

The two tracks

Track 1: the Company is the merchant (first-party sales). Shop checkout creates a payment session in the Company's own processor account. The buyer pays the Company. There is no platform fee taken from the payment and no transfer to a Seller in this path: the books entry debits checking for the full amount and credits revenue net of tax. This is correct while the only seller is the Company itself: products sold by the Company are Sold by Pawz Shop.

Track 2: destination charges (marketplace Seller sales). Under the decided arrangement for third-party Sellers, the buyer's charge carries a platform fee taken at capture, and the remainder routes directly to the Seller's connected account. The payment records already carry the fields for the split: the Seller's account and the platform fee amount. Under the Selling Terms of Service, the Company acts as the Seller's limited agent for collecting the buyer's payment: the buyer's obligation is satisfied when the Company receives the funds, and the Company holds the remedy rights stated there, including transfer reversals and payout freezes.

A payment record with an empty Seller-account field is not broken; it is a first-party, merchant-model payment. When destination charges begin, that field becomes the most important field on the record, and the operator shall not confuse the two tracks when diagnosing a problem.

Connected account tracking

For each tenant, one record tracks its connected processor account: the account identifier, whether charging is enabled, whether payouts are enabled, and whether onboarding is complete. The main business and every franchise tenant link their own bank account through the processor's onboarding; bank details are collected and held by the processor and are never typed into or stored in the Platform.

1. Where a tenant cannot receive payouts, the operator checks these flags first; incomplete onboarding is the usual cause and is visible on the record.
2. The flags are a copy of the processor's position, kept current by the processor's account-update notices. Where the flags and the processor's own console disagree, the processor's console governs, and the operator records the disagreement rather than editing the flags.

Seller identity verification and tax forms at connected-account onboarding are the processor's responsibility, not the accounting team's. The accounting team's responsibility is the onboarding flags and the two halves of every split payment.

The payment records

Two records do two jobs

1. The processor-facing record logs every processor event: charges, refunds (as negative amounts), and subscription payments: recorded once per processor transaction, so a repeated notice never double-counts.
2. The business-facing register is the payment list staff work from: payment number, customer, method, amount, state, and the sale or invoice it belongs to. Subscription payments are mirrored into the register so the administrative views show the revenue; see Sales.

Register records are never deleted. A payment is voided or refunded only with a linked record stating the reason, under Refunds and Disputes. The states in use are pending, succeeded, refunded, and cancelled; only succeeded means money moved.

Working payments: the daily procedure

1. Review the two working filters: payments in pending older than one business day (captures that never completed), and failed payments in the last 24 hours (customers to contact about retrying). Check failure codes before contacting anyone; a sudden fall in the success rate is almost always a processor or connection problem, not a customer problem.
2. Resolve every stale pending payment: it is either a capture that never completed or an authorization that will expire.
3. Recording a manual payment: for phone orders, in-person catch-ups, and corrections: creates the register record as succeeded, using the tenant's manual cash method where none is supplied. A manual payment posts no journal entry; the register shows the money and the books do not. The operator flags every manual payment for the manual reconciliation in Troubleshooting (Accounting Troubleshooting). Before recording anything by hand, match on the processor payment identifier: the processor-facing record cannot duplicate, but the register can, and a mirrored subscription payment plus a manual entry for the same charge is the classic double count.
4. Receipts print from the payment record. Reprinting is always safe and changes nothing. A payment shall never be recreated to generate a receipt.
5. Batch export for the bank or the tax preparer is run only after the period's payments are final and reconciled. Exporting mid-day and again the next morning double-counts everything that arrived in between.

Money movement for marketplace Sellers

When destination charges begin, the sequence the records are shaped for is

1. At checkout, one charge for the full order amount.
2. At capture, the processor splits it: the platform fee is taken first, and the remainder lands directly in the Seller's connected account balance.
3. The payment record preserves both halves: the Seller's account and the platform fee. The Company's books show fee revenue; the Seller's side shows sale proceeds. Neither side shows the other's money as its own.
4. Between checkout and the Seller's payout date, funds sit in the Seller's connected account balance: not in the Company's bank account and not yet in the Seller's bank account. The Company never holds third-party funds in its own bank account: buyer to processor to Seller. The Company directs the flow; it does not hold the funds.
5. Seller payouts settle on a 7–14 day rolling delay, keeping funds available while the dispute window is open. The Seller's balance therefore shows an available amount and a held amount; a Seller asking why a balance has not paid out is asking about this delay.

A dispute decided against the Seller triggers a transfer reversal: the disputed amount is pulled back out of the Seller's balance and appears as a transaction against the Seller. Where the Company returns its own fee to make the buyer whole, that is a reduction of fee revenue, not an expense. Fraud or ignored disputes trigger capability gating: payouts freeze during investigation, which appears in the records as a growing balance with no payouts. That is an enforcement hold, not a defect, and it is released only by the trust and safety decision, under the Chargeback Policy.

Controls

• Separation of duties: the person who records a payment does not reconcile it. Reconciliation is governed by Banking.
• Banking credentials and processor credentials are never shared between operators and are never recorded in a payment record, a memo, or any other document.
• A manual payment shall carry the method and a reference identifying where the money actually arrived. A manual record without a reference is an incomplete record.
• Refunds are issued only under the Returns and Refunds Policy through Refunds and Disputes, never by recreating or editing a payment.

Records created and where they are kept

Payment records, connected account records, receipts, and batch exports are kept in the Platform's commerce and accounting records and retained under the Regulatory Record Retention Policy.

Escalation

Money in the processor with no Platform record, a payment carrying a Seller destination with no Seller account recorded, or any suspected duplicate goes to the Accounting Manager the same day and, where the cause is a system failure, to support@aapawz.com. Chargebacks and legal process go to legal@aapawz.com under the Chargeback Policy.

Review cadence

The Accounting Operator works the payment filters daily. The Accounting Manager reviews manual payments and the pending and failed queues weekly, and reviews this standard when destination charges begin or the processor arrangement changes.