Pine Labs-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Offline payments carry a constraint online payments do not: the customer is standing at the counter and the terminal may lose its network mid-transaction. Machine coding rounds in the style of Pine Labs and other point-of-sale platforms therefore centre on transactions that must survive a device that went away, plus the offer and EMI logic that runs on top of them.
The second half of the domain is money that has to come out even at the end of the day. Settlement batches, merchant fees, and reconciliation against acquirer files are the background against which these rounds grade correctness. This page covers the reported format, what evaluators weight, and Gronex repositories built on the same mechanics.
What a Pine Labs-style machine coding round looks like
A typical statement is a terminal transaction service or an offer engine: authorise, capture, void, and refund against a card transaction; or apply merchant-funded offers and EMI plan eligibility to a sale amount. Rules arrive concretely — a void is only legal before settlement, a refund after it, cumulative refunds may not exceed the captured amount, an offer applies once per transaction and only above a minimum ticket size.
The auth-and-capture distinction is the part candidates most often flatten, and it is exactly what the round is looking at. Authorisation reserves; capture moves money; a void kills an uncaptured authorisation; a refund reverses a captured one. Four verbs, one state machine, and a set of illegal pairs that must be rejected with specific errors rather than a generic failure. If your model has a single "amount paid" field, three of the four verbs become ambiguous.
Offer and EMI math then tests exactness. Tenure-based interest subvention, cashback caps, and no-cost-EMI splits all produce fractions, and the round expects integer minor units with a stated rounding rule, so the terminal slip, the ledger, and the settlement file agree to the paisa. Expect a follow-up that adds a stacked offer or a new tenure and watches whether your plan definitions were data.
How you’re evaluated
Auth, capture, void, refund
Four distinct operations with legal ordering enforced centrally, and specific errors for the illegal pairs rather than one catch-all failure.
Cumulative refund caps
Partial refunds tracked so their sum can never exceed what was captured, however many arrive or repeat.
Exact offer and EMI math
Integer minor units, a declared rounding rule, and totals that reconcile — no float drift between slip, ledger, and settlement.
Reconciliation readiness
An entry trail per transaction that a settlement batch can be rebuilt from, including transactions that failed halfway.
Common mistakes that fail this round
- Modelling the sale as paid or unpaid, which makes void-versus-refund impossible to express correctly.
- Allowing a void after settlement or a refund before capture because the transition table was never written down.
- Tracking only the latest refund instead of the cumulative total, so two partial refunds exceed the sale.
- Computing EMI interest and cashback caps in floating point and discovering a one-paisa mismatch during the demo.
- Treating a terminal retry after a dropped connection as a new sale instead of the same one re-submitted.
Quick tips for the room
- Name the four verbs out loud and draw the legal transitions first.
- Track captured, voided, and refunded amounts separately from the sale total.
- Keep money in paise with one rounding helper used everywhere.
- Ask whether a retried sale carries a client-side reference — then use it as the key.
How to prepare
Write the four-verb transition table before any code, including which verbs are legal in which state and what each illegal combination returns. Then implement partial refunds with a cumulative cap and a replayed request that must be a no-op. Those two pieces are the spine of nearly every in-store payments statement.
The repositories below cover the spine and the edges: the wallet problem drills cumulative refund caps and idempotent mutations, the escrow problem is hold-then-release under concurrency, the ledger problem is the reconciliation half, and the subscription engine covers the plan-and-proration math that EMI tenures resemble closely. The duplicate-side-effects problem (free) is the dropped-connection retry made concrete.
Practice problems in the Pine Labs-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Wallet Transaction & Refund System
Cumulative refund caps, idempotent debits, and ledger consistency — the refund rules that terminal flows live by.
Open the challenge →Escrow Hold & Release
Authorise-then-settle as a concurrency problem: held balances released exactly once, with terminal-state guards.
Open the challenge →Billing & Proration Engine
Plan math without float drift: tenure changes, proration, and idempotent invoicing to the exact minor unit.
Open the challenge →Payment Ledger Consistency
The settlement side: append-only entries that still balance after partial failures and replays.
Open the challenge →Duplicate Charges After a Restart
The re-submitted sale: make an at-least-once pipeline produce exactly one charge. Free to try.
Open the challenge →FAQ
Are these actual Pine Labs interview questions?
No. They are Gronex originals in the style of in-store payments rounds — the kind of problem asked in rounds like Pine Labs’. Gronex is not affiliated with Pine Labs and does not republish company questions.
Why does auth-versus-capture matter so much?
Because every legality rule in the domain hangs off it: voids apply to authorisations, refunds to captures, and settlement only sees captures. Candidates who model one amount field cannot express those rules, and the reviewer finds out in the first two questions.
Is offline or network-loss handling expected in the build?
Not as infrastructure. What is expected is that a re-submitted transaction with the same client reference is recognised as the same transaction — which you can demonstrate entirely in memory.
How is this different from a UPI-style payments round?
Online payment rounds lean on idempotency and event streams. In-store rounds add the four-verb card lifecycle and merchant-side money — offers, EMI tenures, fees, and end-of-day settlement — so exact arithmetic gets as much attention as retry safety.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Pine Labs. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from Pine Labs.