Skip to content

POS billing & payments

Sellerlane POS is designed for a real counter: one customer can wait while you bill another, without merging their carts or losing a payment that is still settling. Each sale tab owns its customer, items, discounts, delivery choice, notes, stock reservation, loyalty holds, checkout, and payment attempt.

Diagram viewer: scroll horizontally to inspect the full flow.

Several independent POS sale tabs remain separate. Only the selected tab renders as the active cart, which can present a QR, send a payment link, or open hosted checkout before reconciliation completes that sale.
Switching tabs never copies one buyer's cart or payment state into another sale. A completed sale leaves the strip after a safe next tab or replacement cart is ready.

Work with several customers

You can keep up to 10 open sales per store in one browser.

  1. Select New sale. Sellerlane reuses the current tab when it is already an empty sale, so the register does not accumulate blank carts.

  2. Rename a tab to something recognizable, such as Asha, Table 4, or Pickup 5:30. Otherwise it keeps its automatic Sale number.

  3. Switch tabs while another customer decides or completes payment. Every tab shows its name, item count, total, and a readable Checkout open or Payment pending badge.

  4. Finish the active sale. Only that tab is completed; the waiting tabs keep their exact carts and checkout state.

The browser stores only a small, store-scoped tab registry: cart reference, human label, item count, total/currency, location, and checkout-state summary. The authoritative cart stays on the server. Email, phone, card data, payment payloads, and tokens are not copied into local tab storage.

Discard a sale safely

Discard sale closes the server session and supersedes its current payment attempt. A merely created attempt becomes canceled; a pending attempt queues a provider cancel operation; an authorized attempt queues a void. Checkout, loyalty, and stock holds are released by that server cleanup. If closing fails, Sellerlane keeps the tab so the cashier can retry instead of hiding unfinished work. If it was the last tab, a replacement empty sale is opened before the register leaves the old route.

Gateway actions at POS

The buyer should use their own phone or a gateway-hosted page. The cashier does not type a visitor’s card number into the seller admin.

ActionBuyer experienceDelivery
QR code Buyer scans a Sellerlane secure payment URL, which opens the connected gateway checkoutShown on the register; this is a scan-to-open hosted-checkout bridge, not a claimed provider-native UPI payload
Payment link Buyer opens the same safe launch page on their own deviceShow on register, send by configured SMS, or send by email
Hosted checkout Opens the provider checkout flowUse on a safe buyer-facing device or handoff flow
Manual method Cash, external terminal, bank transfer, manual UPI, or another offline processCashier records reference/collection according to the method’s settlement policy

Sellerlane never sends a bare provider secret, form payload, or SDK session in an SMS/email. The public link contains an unguessable Sellerlane payment-attempt capability; the launch page retrieves the current provider action server-side.

Razorpay, PayU, and Cashfree

For INR POS sales, Razorpay, PayU, and Cashfree can be presented through:

  • a Sellerlane scan-to-open QR bridge;
  • a Sellerlane payment link;
  • the provider’s hosted checkout.

The method settings can narrow the allowed actions and choose a default. If the stored restriction is invalid or has no compatible action, Sellerlane hides the method and fails closed rather than silently widening the merchant’s policy. Online checkout remains hosted-checkout only.

“Queued” is not “received”

The success message appears only after a durable SMS/email outbox accepts the link. It says the delivery was queued, because carrier acceptance and handset delivery happen asynchronously. If dispatch is unavailable or the contact is missing, the cashier can display the link or QR instead.

Payment lifecycle

Starting a gateway action creates one attempt for the prepared quote, method, amount, currency, mode, delivery, recipient, and return context. A materially different request does not reuse the wrong QR or link.

Webhooks and reconciliation update the attempt. The order is completed as paid only after confirmed capture; delayed callbacks do not require the cashier to keep the modal open.

Changing the selected payment method or action after preparation requires Prepare again. Sellerlane does not complete a quote using the stale method. Return and cancel URLs are server-derived for POS, so redirect gateways can land on the safe payment-status page even when the register supplied no buyer URL.

Carry-out, pickup, and delivery

POS orderAddress behaviorFulfillment behavior
Carry-outNo shipping or billing address requiredUses the selling location; eligible no-ship items can complete after payment
Pickup orderNo shipping addressPickup group/location is explicit; no carrier package is created
Ship to customerShipping address requiredAdding an address enters delivery mode; select a shipping option and Sellerlane routes/reserves from eligible locations

For a ship-to-customer sale, the register location is the preferred origin, not a guarantee. If another eligible location provides the valid route and stock, the order can receive a fulfillment order for that location.

Loyalty and customer identity at POS

  • A named customer can use the same loyalty account and ledger online and in store, subject to the redemption rule’s explicit POS channel eligibility.
  • A walk-in customer can remain contactless. Do not invent an email or phone to force identity.
  • Sending a payment link requires the corresponding phone or email for that delivery only; it does not grant unrelated marketing consent.
  • Referral attribution is order/customer based. A normal walk-in sale does not inherit an online referral merely because the advocate previously shopped.

Counter examples

Asha’s three-item sale is open. Rename it Asha, select New sale, and bill Ravi. When Asha is ready, switch back; her discounts, customer, stock reservations, and total are unchanged.

Troubleshooting

  • New sale is disabled — finish one of the 10 open sales, or allow browser storage if the register reports a persistence error.
  • Discard did not finish — the server close or provider cleanup could not be accepted. The tab stays visible; retry it or reconcile the attempt instead of deleting browser state.
  • A gateway action is missing — check that the method is Active, POS-enabled, compatible with the order currency, and has a valid allowed-action set.
  • The buyer did not receive a link — “queued” confirms outbox acceptance, not handset delivery. Verify the contact and messaging configuration, then display the QR/link as fallback.
  • Payment completed but the tab still says pending — refresh/reconcile the active sale. The backend webhook/sweep remains authoritative and idempotent.

Payments

Connect gateways, configure action modes, and add manual methods in Payments.

Order & rewards lifecycle

Understand payment gates, COD, fulfillment, self-service, and rewards in Order & rewards lifecycle.

Manual payment methods

Configure cash, terminal, COD, bank transfer, and manual UPI in Manual payment methods.