The Hard Part Comes After the Pay Button
Payment integration often looks finished the moment the PG SDK is wired up and a test transaction goes through. The real problems show up once you're live. A customer gets a payment confirmation text, but the order is nowhere in the system. A double-click produces two approvals for the same amount. A partial refund leaves the PG's cancellation amount and your internal refund record a few hundred won apart.
For a service handling 1,000 orders a day, a 0.3% miss rate means 3 broken orders daily, or roughly 90 a month. Each one requires a support agent to flip between the PG dashboard and your database to fix it by hand, and slow resolution turns into complaints and card chargebacks. The quality of a payment system isn't decided by the checkout button. It's decided by state management and settlement behind it.
Designing the Core Payment Flow
Define States First
At minimum, an order should move through these stages:
Allow transitions in one direction only, and record every transition in a history table so you can trace problems later.
Never Trust the Client
The "payment succeeded" parameters a browser sends back can be tampered with or replayed. A classic attack pays 1,000 won for a 100,000-won order and then fires only the success callback. The server must query the PG directly and confirm that the approval status, amount, and order ID match what was set when the order was created.
Webhooks and Idempotency
If a user closes the window right after paying, the redirect never arrives. PG webhooks are what rescue those orders. But webhooks can be delivered more than once, so idempotent handling keyed on the payment's unique ID is essential: if the same key arrives again, return the existing result and make sure the state changes only once. Attaching an idempotency key to approval requests also stops double-click duplicate charges.
Recurring Billing and Partial Refunds
Billing-Key Subscriptions
With recurring billing, the server uses a billing key issued at first authentication to request approval each cycle. Failures from exceeded limits or expired cards are common, so set a clear policy such as retries after 1, 3, and 7 days, and send the customer a link to update their payment method after each failure. Rather than cancelling immediately after the final retry, moving to a grace state (PAST_DUE) helps reduce churn.
Refunds on Orders With Coupons and Points
Say a customer places a 100,000-won order, uses a 10,000-won coupon and 5,000 won in points, and pays 85,000 won by card. They then return one item worth 40,000 won. Allocating discounts by item share (40%) deducts 4,000 won of coupon and 2,000 won of points, so the card partial cancellation is 34,000 won. If you don't store the per-item allocation at order time, the math will come out differently every time you process a refund.
Proration on Plan Changes
If a customer on a 30,000-won monthly plan (30-day cycle) upgrades to a 90,000-won plan on day 11, the difference for the remaining 20 days is 60,000 × 20/30 = 40,000 won. Decide explicitly whether to charge immediately or on the next billing date, and show the same rule in your terms and on the checkout screen to avoid disputes.
Reconciliation and Operations
Automated Daily Reconciliation
Pull the PG's settlement file or API data every day and match it against your internal payment table by payment key. Mismatches usually fall into four types:
An admin screen with per-type lists, one-click re-query, and assignee and note tracking cuts support handling time significantly.
Storage Scope and Security
Never store full card numbers or CVCs. Keep only the billing key and a masked card number. Verify webhooks by signature or source IP, and keep payment API keys in server-side environment variables only. Korean law requires electronic financial transaction records to be retained (one or five years depending on the amount), so your deletion policy has to follow that rule too.
How POLYGLOTSOFT Helps You Build Payments
Each service type has its own pressure points: partial cancellations and coupon allocation for online stores, recurring billing and proration for SaaS, and cancellation fees and no-show policies for booking services. POLYGLOTSOFT builds the full stack for your service type, from payment state design and idempotent webhook handling to automated reconciliation jobs and admin settlement screens. With our subscription development service (from ₩290,000 a month), the same team stays on after launch to handle operational issues like settlement mismatches and PG policy changes. If you have a payment integration coming up, try writing a requirements document or reach out through our contact page for a consultation.