{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"en","schema_type":"TechArticle","category":"how_to","category_name":"How-to","title":"7 Things to Decide First When Building an AI-Powered Payment Feature","summary":"While AI can quickly generate payment codes, the security of payment functionality depends on policy design—such as order status, refund deadlines, partial refunds, and prevention of duplicate payments. In particular, for e-commerce services in South Korea, development requirements must clearly incorporate provisions for the right to cancel, interest on delayed refunds, disclosure of refund policies, and the avoidance of dark patterns.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["The payment feature is not merely a card authorization function, but an operational system that integrates ordering, settlement, refunds, customer service, and legal notices.","Order statuses—such as \"Pending Payment,\" \"Payment Complete,\" \"Canceled,\" \"Refund in Progress,\" and \"Refund Complete\"—must be defined in a way that ensures both customers and administrators understand them to mean the same thing.","In the Korean e-commerce sector, it is generally necessary to take into account the consumer’s right to cancel a purchase, the merchant’s deadline for processing refunds, and regulations regarding late payment interest.","Simply disabling the button is not sufficient to prevent double payments; server-side idempotency keys, order locking, and duplicate payment approval checks are required.","Designs that hide refund policies and cancellation procedures or make it difficult to cancel a subscription undermine customer trust and increase the risk of regulation targeting dark patterns."],"content_markdown":"## Key Summary\n\nThe most dangerous prompt when entrusting payment functionality to AI is simply asking it to “handle the payment.” Payment is not just a code for receiving money; it is an operational, accounting, and customer support system responsible for managing the flow of funds.\n\nTechnically, AI can quickly implement payment window integration, API calls for authorization, webhook reception, and order storage. However, if the following policies are not established, real-world services may face issues such as phantom orders, duplicate payments, delayed refunds, customer service overload, and missing legal disclosures.\n\n| Decision Area | Questions to Define in Advance | Risks of Failure |\n|---|---|---|\n| Order Status | What sequence of statuses does an order go through? | Ghost orders occur where payment is processed but no order exists |\n| Refund Deadline | How will we account for the deadlines for cancellation of purchase and refund processing? | Violation of statutory deadlines, late payment interest, risk of disputes |\n| Partial Refunds | How will we calculate refunds for partial returns, coupons, and shipping costs? | Operators must calculate manually each time, leading to customer distrust |\n| Double Payments | How can we prevent the same order from being charged twice? | Customer complaints based on credit card statements, loss of trust |\n| Failure Notifications | How should we notify customers of credit limit exceeded, insufficient balance, or authentication failure? | Decreased retry conversion rate, increase in unnecessary inquiries |\n| Payment History | Where can customers check the status of their payments and refunds? | Increased customer service inquiries, lack of transparency |\n| Refund Notices | Where should refund policies and the cancel button be placed? | Controversy over “dark patterns,” regulatory risks |\n\n## 1. Order Status Design: Status Is the Language of Operations\n\nWhen building a payment feature, you shouldn’t limit order statuses to just “Order Complete.” Actual orders go through multiple stages, such as payment attempt, approval, cancellation, refund, failure, and expiration.\n\n### Recommended Status Examples\n\n| Example Status Codes | Status Visible to the Customer | Meaning |\n|---|---|---|\n| `payment_pending` | Payment Pending | The order has been created, but payment is not yet complete |\n| `paid` | Payment Complete | Payment has been approved, and the order is valid |\n| `payment_failed` | Payment Failed | The payment attempt failed, and you must determine whether a retry is possible |\n| `cancel_requested` | Cancellation Request | The customer has requested a cancellation, and it is pending processing |\n| `cancelled` | Cancellation Complete | The order was canceled before payment, or the authorization was revoked |\n| `refund_requested` | Refund Request | A refund request was received after payment |\n| `refund_processing` | Refund in Progress | The refund is being processed or the funds are being returned to the payment method |\n| `partially_refunded` | Partial Refund Complete | Only a portion of the order amount has been refunded |\n| `refunded` | Refund Complete | Refund processing is complete |\n| `expired` | Order Expired | The order has been invalidated because the payment waiting period has expired |\n\n### Status Design Principles\n\n- Order status and payment status are not considered entirely equivalent. An order may exist even if payment fails, and payment may be approved even if the order fails to be saved.\n- For every status change, the time of occurrence, processor, reason, payment transaction ID, and refund transaction ID must be logged.\n- The customer interface, admin interface, and customer service responses must all use the same status definitions.\n- Status transitions are designed to be unidirectional, and exception recovery is handled by logging the event with separate administrative permissions.\n\n## 2. Right of Withdrawal and Statutory Refund Period: These Are Legal Requirements, Not Just Policies\n\nIf you operate consumer-facing e-commerce in South Korea, you must comply with the Act on Consumer Protection in Electronic Commerce, etc. Generally, consumers may withdraw their purchase within a specified period, and businesses must refund the payment within a set timeframe following a refund request or return process.\n\nThe following criteria are particularly important in practice:\n\n- In principle, consumers may withdraw from a contract within 7 days from the date they received the goods or other items, or from another date specified by law.\n- Businesses must refund the payment within the statutory deadline after the grounds for a refund arise; delays may result in claims for compensation for delay or late payment interest.\n- Exceptions may apply to digital content, custom-made products, and goods whose value significantly diminishes with use; however, to apply these exceptions, requirements such as prior notice and consent must be carefully verified.\n- Actual application may vary depending on the type of product, contract method, notices provided to the consumer, and whether use has commenced; therefore, legal review is necessary.\n\n### How to Convert These into Development Requirements\n\nIt is not sufficient to simply include legal standards in the terms and conditions. They must also be converted into system requirements.\n\n| Legal/Policy Requirements | System Requirements |\n|---|---|\n| Determining eligibility for withdrawal within 7 days | Automatically calculate the refund period based on the order receipt date or service provision date |\n| Refunds must be processed within 3 business days | Display the refund request date and processing deadline on the admin dashboard |\n| Risk of refund delays | Display notifications for approaching deadlines and missed deadlines |\n| Requirement to notify customers of exempt products | Clearly indicate before payment that the product is subject to refund restrictions and store consent logs |\n| Requirement to handle disputes | Retain records of terms and conditions version, notification time, consent time, and customer IP or account logs |\n\n## 3. Partial Refund Rules: Predefine Coupons, Shipping Fees, and Taxes\n\nPartial refunds are much more complex than full cancellations. When a customer orders multiple products at once and returns only some of them, you must determine how to allocate the original discounts and shipping fees.\n\n### Items That Must Be Determined\n\n- How to allocate the payment amount per item\n- Whether to allocate order-wide coupons proportionally across items\n- Whether coupons for specific items should apply only to those items\n- Whether to deduct shipping fees when free shipping conditions are no longer met\n- How to distinguish between shipping fees for returns due to buyer’s remorse and those for defective products\n- In what order should refunds be issued for payments made with points, stored credit, and gift cards?\n- How should the information on tax invoices, cash receipts, and sales receipts be updated after a partial refund?\n\n### Example of Partial Refund Calculation\n\n| Item | Amount |\n|---|---:|\n| Product A | 30,000 KRW |\n| Product B | 70,000 KRW |\n| Order-wide Coupon | -10,000 KRW |\n| Actual Payment Amount | 90,000 KRW |\n\nIf the coupon is allocated based on the proportion of each item’s price, Product A receives a 3,000 KRW discount and Product B receives a 7,000 KRW discount. In this case, if only Product A is refunded, the refund base amount is 27,000 KRW, not 30,000 KRW. The final refund amount may vary further if there are free shipping conditions, return shipping fees, or refund restrictions based on the payment method.\n\nThere is no single “correct” answer. What matters is establishing consistent rules in advance and clearly communicating them to customers so they can understand them before making a payment or requesting a refund.\n\n## 4. Preventing Double Charges: Simply Disabling the Button Is Not Enough\n\nDouble charges are the payment issues customers notice most quickly. Customers see their card approval text messages and credit card statements before they check the order status within the service. If the same order is charged twice, trust in the service plummets.\n\n### Causes\n\n- The customer clicks the payment button repeatedly\n- The customer refreshes the page or clicks the “Back” button immediately after payment\n- The same request is resent due to mobile network latency\n- The payment authorization response was successful, but saving to the service server failed\n- A webhook and client redirect simultaneously change the order status\n\n### Defense Design\n\n| Defense Mechanism | Description |\n|---|---|\n| Client Button Lock | Prevents repeated clicks on the payment button after the initial click, but should only be used as a secondary measure |\n| Server-Side Order Lock | Ensures that payment approval requests for the same order ID are not executed simultaneously |\n| Idempotency Key | Uses an identifier that ensures only one result is generated even if the same payment request is sent multiple times |\n| Unique Transaction ID | Prevents duplicate storage of order numbers and payment transaction IDs via database constraints |\n| State-Based Validation | Prevents additional authorization requests for orders already marked as `paid` |\n| Duplicate Webhook Handling | Ensures that even if the same webhook event is received multiple times, the state is updated only once |\n\nWhen requesting a payment code from an AI, it is best to specify that “payment approval and payment completion for the same order must behave idempotently,” rather than simply stating “prevent duplicate clicks.”\n\n## 5. Payment Failure Messages: Failure Is Not an Accident, but a Normal Part of the Process\n\nPayment failures are normal occurrences that happen every day. Exceeding spending limits, insufficient funds, failed card authentication, incorrect passwords, failed 3D Secure authentication, unresponsive mobile payment apps, and network errors are all common cases.\n\nA poor error message is one that simply ends with “An error has occurred.” Customers have no way of knowing whether the payment went through, if they should try again, or if their order has been canceled.\n\n### Example Error Messages\n\n| Situation | Recommended Message |\n|---|---|\n| Insufficient Balance | The payment could not be completed because the balance on your payment method is insufficient. Please select a different payment method or check your balance and try again. |\n| Limit Exceeded | The payment failed because it exceeded your card limit or the single-transaction limit. Please check your limit in the card issuer’s app or pay with a different card. |\n| Authentication Failed | Payment authentication was not completed, so the order remains in a pending status. You can try again within 30 minutes. |\n| Network Error | There is a delay in confirming the payment result. To prevent duplicate payments, please check your payment history after a short while. |\n| Order Expired | The payment waiting period has expired, and the order has been canceled. Please select the items again and place a new order. |\n\n### Key Elements of Failure Notifications\n\n- Clearly states that the payment was not actually completed.\n- Indicates how long the order will remain active.\n- Provides guidance on whether to retry or use a different payment method.\n- Displays the order number needed when contacting customer support.\n- If the payment result is uncertain, do not automatically prompt the user to pay again; instead, display a “Verifying” status.\n\n## 6. Payment History Page: The Key Screen for Reducing Customer Support Inquiries\n\nWithout a payment history page, customers will contact customer support to check the status of their payments, cancellations, and refunds. The payment history is not just a simple receipt screen; it is a trust mechanism that allows customers to verify the current status of their funds.\n\n### Information to Include on the Payment History Page\n\n- Order number\n- Order date and time, and payment date and time\n- Product name, quantity, and options\n- Payment method and authorization number or transaction identifier\n- Product price, discounts, shipping fees, points used, and final payment amount\n- Current order status and refund status\n- Refund request date, refund approval date, and expected refund completion date\n- Whether cancellation or refund is possible\n- Links to view the receipt, transaction statement, and cash receipt\n- Information needed when contacting customer service\n\n### Integration with the Administrator Dashboard\n\nThe customer interface and the administrator dashboard must display the same data. If a customer sees “Refund in Progress” but the administrator dashboard shows “Processed,” it will cause confusion when handling customer service inquiries. While status names may be expressed differently, the internal status codes and transition rules must be consistent.\n\n## 7. Location of Refund Policy Notice: Hiding It Turns a Policy into a Risk\n\nIt is not enough to place the refund policy in a corner of the Terms and Conditions page. Customers must be able to easily check the refund window, restrictions, and cancellation methods on the screen where they make their payment decision.\n\n### Recommended Display Locations\n\n- Near the price or “Buy” button on the product detail page\n- On the shopping cart or order summary screen\n- In the terms and conditions and refund policy consent section immediately above the checkout button\n- On the payment confirmation page\n- On the order details screen in the “My Account” section\n- On the refund request screen\n\n### Designs to Avoid\n\n- Designs where sign-up and payment occur simultaneously, but cancellation or refunds are only possible by calling customer service\n- Designs that hide the cancellation button deep within multiple steps\n- Designs that only display refund restrictions after payment has been made\n- Designs that arrange button colors, text, and order in a way that misleads customers\n- Designs that fail to clearly notify customers of automatic billing after a free trial ends\n\nSuch designs not only harm the customer experience but may also be classified as dark patterns. In particular, it is safest to design the difficulty of cancellation and termination so that it is not significantly different from that of sign-up and payment.\n\n## Checklist to Include in the Prompt for the AI\n\nWhen requesting the implementation of payment functionality from an AI development tool, you must first provide the policies as shown below.\n\n### Example Prompt for Payment Functionality\n\n```text\nImplement payment functionality for an e-commerce service targeting Korean consumers.\nBe sure to incorporate the following policies:\n\n1. Use the following order statuses: payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, and expired.\n2. Change pending orders to “expired” after 30 minutes.\n3. Allow only one payment approval per order, and use server-side order locking and an idempotency key.\n4. Since payment webhooks may be received multiple times, process each event ID only once.\n5. Store the refund request date, refund processing deadline, processor, reason, and refund transaction number.\n6. Calculate partial refunds based on the actual payment amount per item, and allocate order-wide coupons proportionally based on the item prices.\n7. In the event of a payment failure, return a customer notification message specific to the reason for the failure.\n8. Allow customers to view their payment history and refund status on their My Page.\n9. Display a link to the refund policy and a consent checkbox before payment, and save the time of consent and the terms and conditions version.\n10. If there are any unspecified policies, please ask before writing any code.\n```\n\nThe last sentence, “If there are any unspecified policies, please ask first,” is important. It allows the AI to prompt for clarification on policies that humans might easily overlook, such as whether refunds are automatically approved, who has approval authority, and how shipping fees are deducted.\n\n## Required Features for the Admin Dashboard\n\nThe payment functionality isn’t complete with just the customer interface. Since refunds and cancellations are daily operational tasks, an admin interface is essential.\n\n| Admin Features | Reason |\n|---|---|\n| Pending Refunds List | Necessary to ensure no pending refunds are missed |\n| Display of Legal Processing Deadlines | Necessary to reduce the risk of delayed refunds |\n| Upcoming and Overdue Alerts | Necessary so operators can immediately recognize internal deadlines, such as 3 business days |\n| Refund Reason Selection | Necessary for statistics and cost allocation (e.g., change of mind, defective product, incorrect delivery) |\n| Partial Refund Calculation Preview | Required to reduce manual calculation errors by operators |\n| Processing Log | Required for dispute resolution and audit compliance |\n| Permissions Management | Required to restrict refund approvals and forced status changes |\n\n## Minimum Configuration of the Payment Data Model\n\nAlthough data structures vary by service, it is recommended to at least separate the data into the levels listed below.\n\n| Table or Object | Key Fields |\n|---|---|\n| Order | Order ID, Customer ID, Order Status, Order Amount, Discount Amount, Shipping Cost, Creation Date/Time, Expiration Date/Time |\n| Order Items | Item ID, Item Name, Options, Quantity, Amount per Item, Discount Allocation per Item |\n| Payment | Payment ID, Order ID, Payment Method, Authorization Number, Authorized Amount, Payment Status, Authorization Date and Time |\n| Refund | Refund ID, Order ID, Refund Amount, Refund Reason, Refund Status, Request Date/Time, Completion Date/Time |\n| Status History | Target ID, Previous Status, New Status, Modifier, Reason for Change, Date/Time of Change |\n| Terms of Service Agreement | Terms Type, Terms Version, Agreement Status, Agreement Date/Time, Customer ID |\n\nIt is crucial not to overwrite the approved payment amount, refund amount, or total order amount. Values related to money should be preserved by transaction and history unit whenever possible to ensure consistency with accounting records and customer service later on.\n\n## Pre-Launch Checklist\n\n- If the payment button is clicked 10 times for the same order, is the payment approved only once?\n- If server storage fails after payment approval, can the data be recovered?\n- If the payment webhook sends the same event multiple times, is it processed without duplication?\n- Can customers understand the reason for payment failure and how to retry?\n- Do pending payment orders automatically expire after a certain period?\n- Do partial refund amounts comply with coupon, point, and shipping fee policies?\n- Are refund requests displayed on the admin dashboard from the request date until the processing deadline?\n- Are the refund policies easily visible on the pre-payment screen?\n- Are there prior notifications and consent logs for digital content or products with refund restrictions?\n- Can customers check their payment history and refund status directly in their account dashboard?\n\n## Conclusion\n\nAI can quickly generate code for payment functionality. However, a secure and legally compliant payment system begins with policy decisions made before any code is written.\n\nBy first defining order statuses, statutory refund deadlines, partial refund calculation formulas, measures to prevent duplicate payments, payment failure notifications, the payment history page, and the location for displaying refund policies—and then entrusting the implementation to AI—you can achieve much more stable results. Payment systems should be designed from the perspective that they are not merely a “function for receiving money,” but a “function for managing money.”","content_html":"\u003ch2\u003e\n\u003ca href=\"#key-summary\" class=\"anchor\" id=\"key-summary\"\u003e\u003c/a\u003eKey Summary\u003c/h2\u003e\n\u003cp\u003eThe most dangerous prompt when entrusting payment functionality to AI is simply asking it to “handle the payment.” Payment is not just a code for receiving money; it is an operational, accounting, and customer support system responsible for managing the flow of funds.\u003c/p\u003e\n\u003cp\u003eTechnically, AI can quickly implement payment window integration, API calls for authorization, webhook reception, and order storage. However, if the following policies are not established, real-world services may face issues such as phantom orders, duplicate payments, delayed refunds, customer service overload, and missing legal disclosures.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eDecision Area\u003c/th\u003e\n\u003cth\u003eQuestions to Define in Advance\u003c/th\u003e\n\u003cth\u003eRisks of Failure\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003eOrder Status\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eWhat sequence of statuses does an order go through?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eGhost orders occur where payment is processed but no order exists\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003eRefund Deadline\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eHow will we account for the deadlines for cancellation of purchase and refund processing?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eViolation of statutory deadlines, late payment interest, risk of disputes\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003ePartial Refunds\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eHow will we calculate refunds for partial returns, coupons, and shipping costs?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eOperators must calculate manually each time, leading to customer distrust\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003eDouble Payments\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eHow can we prevent the same order from being charged twice?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eCustomer complaints based on credit card statements, loss of trust\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003eFailure Notifications\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eHow should we notify customers of credit limit exceeded, insufficient balance, or authentication failure?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eDecreased retry conversion rate, increase in unnecessary inquiries\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003ePayment History\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eWhere can customers check the status of their payments and refunds?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eIncreased customer service inquiries, lack of transparency\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Decision Area\"\u003eRefund Notices\u003c/td\u003e\n\u003ctd data-label=\"Questions to Define in Advance\"\u003eWhere should refund policies and the cancel button be placed?\u003c/td\u003e\n\u003ctd data-label=\"Risks of Failure\"\u003eControversy over “dark patterns,” regulatory risks\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-order-status-design-status-is-the-language-of-operations\" class=\"anchor\" id=\"1-order-status-design-status-is-the-language-of-operations\"\u003e\u003c/a\u003e1. Order Status Design: Status Is the Language of Operations\u003c/h2\u003e\n\u003cp\u003eWhen building a payment feature, you shouldn’t limit order statuses to just “Order Complete.” Actual orders go through multiple stages, such as payment attempt, approval, cancellation, refund, failure, and expiration.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#recommended-status-examples\" class=\"anchor\" id=\"recommended-status-examples\"\u003e\u003c/a\u003eRecommended Status Examples\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eExample Status Codes\u003c/th\u003e\n\u003cth\u003eStatus Visible to the Customer\u003c/th\u003e\n\u003cth\u003eMeaning\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003ePayment Pending\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe order has been created, but payment is not yet complete\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003ePayment Complete\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003ePayment has been approved, and the order is valid\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003ePayment Failed\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe payment attempt failed, and you must determine whether a retry is possible\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eCancellation Request\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe customer has requested a cancellation, and it is pending processing\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eCancellation Complete\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe order was canceled before payment, or the authorization was revoked\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eRefund Request\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eA refund request was received after payment\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eRefund in Progress\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe refund is being processed or the funds are being returned to the payment method\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003ePartial Refund Complete\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eOnly a portion of the order amount has been refunded\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eRefund Complete\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eRefund processing is complete\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Example Status Codes\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status Visible to the Customer\"\u003eOrder Expired\u003c/td\u003e\n\u003ctd data-label=\"Meaning\"\u003eThe order has been invalidated because the payment waiting period has expired\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#status-design-principles\" class=\"anchor\" id=\"status-design-principles\"\u003e\u003c/a\u003eStatus Design Principles\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eOrder status and payment status are not considered entirely equivalent. An order may exist even if payment fails, and payment may be approved even if the order fails to be saved.\u003c/li\u003e\n\u003cli\u003eFor every status change, the time of occurrence, processor, reason, payment transaction ID, and refund transaction ID must be logged.\u003c/li\u003e\n\u003cli\u003eThe customer interface, admin interface, and customer service responses must all use the same status definitions.\u003c/li\u003e\n\u003cli\u003eStatus transitions are designed to be unidirectional, and exception recovery is handled by logging the event with separate administrative permissions.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-right-of-withdrawal-and-statutory-refund-period-these-are-legal-requirements-not-just-policies\" class=\"anchor\" id=\"2-right-of-withdrawal-and-statutory-refund-period-these-are-legal-requirements-not-just-policies\"\u003e\u003c/a\u003e2. Right of Withdrawal and Statutory Refund Period: These Are Legal Requirements, Not Just Policies\u003c/h2\u003e\n\u003cp\u003eIf you operate consumer-facing e-commerce in South Korea, you must comply with the Act on Consumer Protection in Electronic Commerce, etc. Generally, consumers may withdraw their purchase within a specified period, and businesses must refund the payment within a set timeframe following a refund request or return process.\u003c/p\u003e\n\u003cp\u003eThe following criteria are particularly important in practice:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIn principle, consumers may withdraw from a contract within 7 days from the date they received the goods or other items, or from another date specified by law.\u003c/li\u003e\n\u003cli\u003eBusinesses must refund the payment within the statutory deadline after the grounds for a refund arise; delays may result in claims for compensation for delay or late payment interest.\u003c/li\u003e\n\u003cli\u003eExceptions may apply to digital content, custom-made products, and goods whose value significantly diminishes with use; however, to apply these exceptions, requirements such as prior notice and consent must be carefully verified.\u003c/li\u003e\n\u003cli\u003eActual application may vary depending on the type of product, contract method, notices provided to the consumer, and whether use has commenced; therefore, legal review is necessary.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#how-to-convert-these-into-development-requirements\" class=\"anchor\" id=\"how-to-convert-these-into-development-requirements\"\u003e\u003c/a\u003eHow to Convert These into Development Requirements\u003c/h3\u003e\n\u003cp\u003eIt is not sufficient to simply include legal standards in the terms and conditions. They must also be converted into system requirements.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eLegal/Policy Requirements\u003c/th\u003e\n\u003cth\u003eSystem Requirements\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Legal/Policy Requirements\"\u003eDetermining eligibility for withdrawal within 7 days\u003c/td\u003e\n\u003ctd data-label=\"System Requirements\"\u003eAutomatically calculate the refund period based on the order receipt date or service provision date\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Legal/Policy Requirements\"\u003eRefunds must be processed within 3 business days\u003c/td\u003e\n\u003ctd data-label=\"System Requirements\"\u003eDisplay the refund request date and processing deadline on the admin dashboard\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Legal/Policy Requirements\"\u003eRisk of refund delays\u003c/td\u003e\n\u003ctd data-label=\"System Requirements\"\u003eDisplay notifications for approaching deadlines and missed deadlines\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Legal/Policy Requirements\"\u003eRequirement to notify customers of exempt products\u003c/td\u003e\n\u003ctd data-label=\"System Requirements\"\u003eClearly indicate before payment that the product is subject to refund restrictions and store consent logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Legal/Policy Requirements\"\u003eRequirement to handle disputes\u003c/td\u003e\n\u003ctd data-label=\"System Requirements\"\u003eRetain records of terms and conditions version, notification time, consent time, and customer IP or account logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-partial-refund-rules-predefine-coupons-shipping-fees-and-taxes\" class=\"anchor\" id=\"3-partial-refund-rules-predefine-coupons-shipping-fees-and-taxes\"\u003e\u003c/a\u003e3. Partial Refund Rules: Predefine Coupons, Shipping Fees, and Taxes\u003c/h2\u003e\n\u003cp\u003ePartial refunds are much more complex than full cancellations. When a customer orders multiple products at once and returns only some of them, you must determine how to allocate the original discounts and shipping fees.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#items-that-must-be-determined\" class=\"anchor\" id=\"items-that-must-be-determined\"\u003e\u003c/a\u003eItems That Must Be Determined\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eHow to allocate the payment amount per item\u003c/li\u003e\n\u003cli\u003eWhether to allocate order-wide coupons proportionally across items\u003c/li\u003e\n\u003cli\u003eWhether coupons for specific items should apply only to those items\u003c/li\u003e\n\u003cli\u003eWhether to deduct shipping fees when free shipping conditions are no longer met\u003c/li\u003e\n\u003cli\u003eHow to distinguish between shipping fees for returns due to buyer’s remorse and those for defective products\u003c/li\u003e\n\u003cli\u003eIn what order should refunds be issued for payments made with points, stored credit, and gift cards?\u003c/li\u003e\n\u003cli\u003eHow should the information on tax invoices, cash receipts, and sales receipts be updated after a partial refund?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#example-of-partial-refund-calculation\" class=\"anchor\" id=\"example-of-partial-refund-calculation\"\u003e\u003c/a\u003eExample of Partial Refund Calculation\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eAmount\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduct A\u003c/td\u003e\n\u003ctd data-label=\"Amount\"\u003e30,000 KRW\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduct B\u003c/td\u003e\n\u003ctd data-label=\"Amount\"\u003e70,000 KRW\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eOrder-wide Coupon\u003c/td\u003e\n\u003ctd data-label=\"Amount\"\u003e-10,000 KRW\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eActual Payment Amount\u003c/td\u003e\n\u003ctd data-label=\"Amount\"\u003e90,000 KRW\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIf the coupon is allocated based on the proportion of each item’s price, Product A receives a 3,000 KRW discount and Product B receives a 7,000 KRW discount. In this case, if only Product A is refunded, the refund base amount is 27,000 KRW, not 30,000 KRW. The final refund amount may vary further if there are free shipping conditions, return shipping fees, or refund restrictions based on the payment method.\u003c/p\u003e\n\u003cp\u003eThere is no single “correct” answer. What matters is establishing consistent rules in advance and clearly communicating them to customers so they can understand them before making a payment or requesting a refund.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-preventing-double-charges-simply-disabling-the-button-is-not-enough\" class=\"anchor\" id=\"4-preventing-double-charges-simply-disabling-the-button-is-not-enough\"\u003e\u003c/a\u003e4. Preventing Double Charges: Simply Disabling the Button Is Not Enough\u003c/h2\u003e\n\u003cp\u003eDouble charges are the payment issues customers notice most quickly. Customers see their card approval text messages and credit card statements before they check the order status within the service. If the same order is charged twice, trust in the service plummets.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#causes\" class=\"anchor\" id=\"causes\"\u003e\u003c/a\u003eCauses\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eThe customer clicks the payment button repeatedly\u003c/li\u003e\n\u003cli\u003eThe customer refreshes the page or clicks the “Back” button immediately after payment\u003c/li\u003e\n\u003cli\u003eThe same request is resent due to mobile network latency\u003c/li\u003e\n\u003cli\u003eThe payment authorization response was successful, but saving to the service server failed\u003c/li\u003e\n\u003cli\u003eA webhook and client redirect simultaneously change the order status\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#defense-design\" class=\"anchor\" id=\"defense-design\"\u003e\u003c/a\u003eDefense Design\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eDefense Mechanism\u003c/th\u003e\n\u003cth\u003eDescription\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eClient Button Lock\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003ePrevents repeated clicks on the payment button after the initial click, but should only be used as a secondary measure\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eServer-Side Order Lock\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003eEnsures that payment approval requests for the same order ID are not executed simultaneously\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eIdempotency Key\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003eUses an identifier that ensures only one result is generated even if the same payment request is sent multiple times\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eUnique Transaction ID\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003ePrevents duplicate storage of order numbers and payment transaction IDs via database constraints\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eState-Based Validation\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003ePrevents additional authorization requests for orders already marked as \u003ccode\u003epaid\u003c/code\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Defense Mechanism\"\u003eDuplicate Webhook Handling\u003c/td\u003e\n\u003ctd data-label=\"Description\"\u003eEnsures that even if the same webhook event is received multiple times, the state is updated only once\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eWhen requesting a payment code from an AI, it is best to specify that “payment approval and payment completion for the same order must behave idempotently,” rather than simply stating “prevent duplicate clicks.”\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-payment-failure-messages-failure-is-not-an-accident-but-a-normal-part-of-the-process\" class=\"anchor\" id=\"5-payment-failure-messages-failure-is-not-an-accident-but-a-normal-part-of-the-process\"\u003e\u003c/a\u003e5. Payment Failure Messages: Failure Is Not an Accident, but a Normal Part of the Process\u003c/h2\u003e\n\u003cp\u003ePayment failures are normal occurrences that happen every day. Exceeding spending limits, insufficient funds, failed card authentication, incorrect passwords, failed 3D Secure authentication, unresponsive mobile payment apps, and network errors are all common cases.\u003c/p\u003e\n\u003cp\u003eA poor error message is one that simply ends with “An error has occurred.” Customers have no way of knowing whether the payment went through, if they should try again, or if their order has been canceled.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#example-error-messages\" class=\"anchor\" id=\"example-error-messages\"\u003e\u003c/a\u003eExample Error Messages\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituation\u003c/th\u003e\n\u003cth\u003eRecommended Message\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eInsufficient Balance\u003c/td\u003e\n\u003ctd data-label=\"Recommended Message\"\u003eThe payment could not be completed because the balance on your payment method is insufficient. Please select a different payment method or check your balance and try again.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eLimit Exceeded\u003c/td\u003e\n\u003ctd data-label=\"Recommended Message\"\u003eThe payment failed because it exceeded your card limit or the single-transaction limit. Please check your limit in the card issuer’s app or pay with a different card.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAuthentication Failed\u003c/td\u003e\n\u003ctd data-label=\"Recommended Message\"\u003ePayment authentication was not completed, so the order remains in a pending status. You can try again within 30 minutes.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eNetwork Error\u003c/td\u003e\n\u003ctd data-label=\"Recommended Message\"\u003eThere is a delay in confirming the payment result. To prevent duplicate payments, please check your payment history after a short while.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eOrder Expired\u003c/td\u003e\n\u003ctd data-label=\"Recommended Message\"\u003eThe payment waiting period has expired, and the order has been canceled. Please select the items again and place a new order.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#key-elements-of-failure-notifications\" class=\"anchor\" id=\"key-elements-of-failure-notifications\"\u003e\u003c/a\u003eKey Elements of Failure Notifications\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eClearly states that the payment was not actually completed.\u003c/li\u003e\n\u003cli\u003eIndicates how long the order will remain active.\u003c/li\u003e\n\u003cli\u003eProvides guidance on whether to retry or use a different payment method.\u003c/li\u003e\n\u003cli\u003eDisplays the order number needed when contacting customer support.\u003c/li\u003e\n\u003cli\u003eIf the payment result is uncertain, do not automatically prompt the user to pay again; instead, display a “Verifying” status.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-payment-history-page-the-key-screen-for-reducing-customer-support-inquiries\" class=\"anchor\" id=\"6-payment-history-page-the-key-screen-for-reducing-customer-support-inquiries\"\u003e\u003c/a\u003e6. Payment History Page: The Key Screen for Reducing Customer Support Inquiries\u003c/h2\u003e\n\u003cp\u003eWithout a payment history page, customers will contact customer support to check the status of their payments, cancellations, and refunds. The payment history is not just a simple receipt screen; it is a trust mechanism that allows customers to verify the current status of their funds.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#information-to-include-on-the-payment-history-page\" class=\"anchor\" id=\"information-to-include-on-the-payment-history-page\"\u003e\u003c/a\u003eInformation to Include on the Payment History Page\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eOrder number\u003c/li\u003e\n\u003cli\u003eOrder date and time, and payment date and time\u003c/li\u003e\n\u003cli\u003eProduct name, quantity, and options\u003c/li\u003e\n\u003cli\u003ePayment method and authorization number or transaction identifier\u003c/li\u003e\n\u003cli\u003eProduct price, discounts, shipping fees, points used, and final payment amount\u003c/li\u003e\n\u003cli\u003eCurrent order status and refund status\u003c/li\u003e\n\u003cli\u003eRefund request date, refund approval date, and expected refund completion date\u003c/li\u003e\n\u003cli\u003eWhether cancellation or refund is possible\u003c/li\u003e\n\u003cli\u003eLinks to view the receipt, transaction statement, and cash receipt\u003c/li\u003e\n\u003cli\u003eInformation needed when contacting customer service\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#integration-with-the-administrator-dashboard\" class=\"anchor\" id=\"integration-with-the-administrator-dashboard\"\u003e\u003c/a\u003eIntegration with the Administrator Dashboard\u003c/h3\u003e\n\u003cp\u003eThe customer interface and the administrator dashboard must display the same data. If a customer sees “Refund in Progress” but the administrator dashboard shows “Processed,” it will cause confusion when handling customer service inquiries. While status names may be expressed differently, the internal status codes and transition rules must be consistent.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-location-of-refund-policy-notice-hiding-it-turns-a-policy-into-a-risk\" class=\"anchor\" id=\"7-location-of-refund-policy-notice-hiding-it-turns-a-policy-into-a-risk\"\u003e\u003c/a\u003e7. Location of Refund Policy Notice: Hiding It Turns a Policy into a Risk\u003c/h2\u003e\n\u003cp\u003eIt is not enough to place the refund policy in a corner of the Terms and Conditions page. Customers must be able to easily check the refund window, restrictions, and cancellation methods on the screen where they make their payment decision.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#recommended-display-locations\" class=\"anchor\" id=\"recommended-display-locations\"\u003e\u003c/a\u003eRecommended Display Locations\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNear the price or “Buy” button on the product detail page\u003c/li\u003e\n\u003cli\u003eOn the shopping cart or order summary screen\u003c/li\u003e\n\u003cli\u003eIn the terms and conditions and refund policy consent section immediately above the checkout button\u003c/li\u003e\n\u003cli\u003eOn the payment confirmation page\u003c/li\u003e\n\u003cli\u003eOn the order details screen in the “My Account” section\u003c/li\u003e\n\u003cli\u003eOn the refund request screen\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#designs-to-avoid\" class=\"anchor\" id=\"designs-to-avoid\"\u003e\u003c/a\u003eDesigns to Avoid\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDesigns where sign-up and payment occur simultaneously, but cancellation or refunds are only possible by calling customer service\u003c/li\u003e\n\u003cli\u003eDesigns that hide the cancellation button deep within multiple steps\u003c/li\u003e\n\u003cli\u003eDesigns that only display refund restrictions after payment has been made\u003c/li\u003e\n\u003cli\u003eDesigns that arrange button colors, text, and order in a way that misleads customers\u003c/li\u003e\n\u003cli\u003eDesigns that fail to clearly notify customers of automatic billing after a free trial ends\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSuch designs not only harm the customer experience but may also be classified as dark patterns. In particular, it is safest to design the difficulty of cancellation and termination so that it is not significantly different from that of sign-up and payment.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checklist-to-include-in-the-prompt-for-the-ai\" class=\"anchor\" id=\"checklist-to-include-in-the-prompt-for-the-ai\"\u003e\u003c/a\u003eChecklist to Include in the Prompt for the AI\u003c/h2\u003e\n\u003cp\u003eWhen requesting the implementation of payment functionality from an AI development tool, you must first provide the policies as shown below.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#example-prompt-for-payment-functionality\" class=\"anchor\" id=\"example-prompt-for-payment-functionality\"\u003e\u003c/a\u003eExample Prompt for Payment Functionality\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplement payment functionality for an e-commerce service targeting Korean consumers.\n\u003c/span\u003e\u003cspan\u003eBe sure to incorporate the following policies:\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Use the following order statuses: payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, and expired.\n\u003c/span\u003e\u003cspan\u003e2. Change pending orders to “expired” after 30 minutes.\n\u003c/span\u003e\u003cspan\u003e3. Allow only one payment approval per order, and use server-side order locking and an idempotency key.\n\u003c/span\u003e\u003cspan\u003e4. Since payment webhooks may be received multiple times, process each event ID only once.\n\u003c/span\u003e\u003cspan\u003e5. Store the refund request date, refund processing deadline, processor, reason, and refund transaction number.\n\u003c/span\u003e\u003cspan\u003e6. Calculate partial refunds based on the actual payment amount per item, and allocate order-wide coupons proportionally based on the item prices.\n\u003c/span\u003e\u003cspan\u003e7. In the event of a payment failure, return a customer notification message specific to the reason for the failure.\n\u003c/span\u003e\u003cspan\u003e8. Allow customers to view their payment history and refund status on their My Page.\n\u003c/span\u003e\u003cspan\u003e9. Display a link to the refund policy and a consent checkbox before payment, and save the time of consent and the terms and conditions version.\n\u003c/span\u003e\u003cspan\u003e10. If there are any unspecified policies, please ask before writing any code.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe last sentence, “If there are any unspecified policies, please ask first,” is important. It allows the AI to prompt for clarification on policies that humans might easily overlook, such as whether refunds are automatically approved, who has approval authority, and how shipping fees are deducted.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#required-features-for-the-admin-dashboard\" class=\"anchor\" id=\"required-features-for-the-admin-dashboard\"\u003e\u003c/a\u003eRequired Features for the Admin Dashboard\u003c/h2\u003e\n\u003cp\u003eThe payment functionality isn’t complete with just the customer interface. Since refunds and cancellations are daily operational tasks, an admin interface is essential.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eAdmin Features\u003c/th\u003e\n\u003cth\u003eReason\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003ePending Refunds List\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eNecessary to ensure no pending refunds are missed\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003eDisplay of Legal Processing Deadlines\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eNecessary to reduce the risk of delayed refunds\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003eUpcoming and Overdue Alerts\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eNecessary so operators can immediately recognize internal deadlines, such as 3 business days\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003eRefund Reason Selection\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eNecessary for statistics and cost allocation (e.g., change of mind, defective product, incorrect delivery)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003ePartial Refund Calculation Preview\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eRequired to reduce manual calculation errors by operators\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003eProcessing Log\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eRequired for dispute resolution and audit compliance\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Admin Features\"\u003ePermissions Management\u003c/td\u003e\n\u003ctd data-label=\"Reason\"\u003eRequired to restrict refund approvals and forced status changes\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#minimum-configuration-of-the-payment-data-model\" class=\"anchor\" id=\"minimum-configuration-of-the-payment-data-model\"\u003e\u003c/a\u003eMinimum Configuration of the Payment Data Model\u003c/h2\u003e\n\u003cp\u003eAlthough data structures vary by service, it is recommended to at least separate the data into the levels listed below.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTable or Object\u003c/th\u003e\n\u003cth\u003eKey Fields\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003eOrder\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003eOrder ID, Customer ID, Order Status, Order Amount, Discount Amount, Shipping Cost, Creation Date/Time, Expiration Date/Time\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003eOrder Items\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003eItem ID, Item Name, Options, Quantity, Amount per Item, Discount Allocation per Item\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003ePayment\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003ePayment ID, Order ID, Payment Method, Authorization Number, Authorized Amount, Payment Status, Authorization Date and Time\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003eRefund\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003eRefund ID, Order ID, Refund Amount, Refund Reason, Refund Status, Request Date/Time, Completion Date/Time\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003eStatus History\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003eTarget ID, Previous Status, New Status, Modifier, Reason for Change, Date/Time of Change\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Table or Object\"\u003eTerms of Service Agreement\u003c/td\u003e\n\u003ctd data-label=\"Key Fields\"\u003eTerms Type, Terms Version, Agreement Status, Agreement Date/Time, Customer ID\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIt is crucial not to overwrite the approved payment amount, refund amount, or total order amount. Values related to money should be preserved by transaction and history unit whenever possible to ensure consistency with accounting records and customer service later on.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#pre-launch-checklist\" class=\"anchor\" id=\"pre-launch-checklist\"\u003e\u003c/a\u003ePre-Launch Checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eIf the payment button is clicked 10 times for the same order, is the payment approved only once?\u003c/li\u003e\n\u003cli\u003eIf server storage fails after payment approval, can the data be recovered?\u003c/li\u003e\n\u003cli\u003eIf the payment webhook sends the same event multiple times, is it processed without duplication?\u003c/li\u003e\n\u003cli\u003eCan customers understand the reason for payment failure and how to retry?\u003c/li\u003e\n\u003cli\u003eDo pending payment orders automatically expire after a certain period?\u003c/li\u003e\n\u003cli\u003eDo partial refund amounts comply with coupon, point, and shipping fee policies?\u003c/li\u003e\n\u003cli\u003eAre refund requests displayed on the admin dashboard from the request date until the processing deadline?\u003c/li\u003e\n\u003cli\u003eAre the refund policies easily visible on the pre-payment screen?\u003c/li\u003e\n\u003cli\u003eAre there prior notifications and consent logs for digital content or products with refund restrictions?\u003c/li\u003e\n\u003cli\u003eCan customers check their payment history and refund status directly in their account dashboard?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eAI can quickly generate code for payment functionality. However, a secure and legally compliant payment system begins with policy decisions made before any code is written.\u003c/p\u003e\n\u003cp\u003eBy first defining order statuses, statutory refund deadlines, partial refund calculation formulas, measures to prevent duplicate payments, payment failure notifications, the payment history page, and the location for displaying refund policies—and then entrusting the implementation to AI—you can achieve much more stable results. Payment systems should be designed from the perspective that they are not merely a “function for receiving money,” but a “function for managing money.”\u003c/p\u003e\n","tags":["AI Development","Payment system","Refund policy","E commerce law","Dark patterns"],"faqs":[{"question":"When asking an AI to develop a payment feature, what is the first thing you need to decide?","answer":"First, you need to define the flow of order and payment statuses. Statuses such as “Pending Payment,” “Payment Complete,” “Payment Failed,” “Cancellation Request,” “Refund in Progress,” and “Refund Complete” must be defined so that the AI can create a secure data structure and screen flow."},{"question":"Why is it risky to limit order statuses to just \"Order Complete\"?","answer":"This is because actual payments involve many exception scenarios, such as failures, cancellations, refunds, and expiration. If the status is too simple, issues may arise—such as a payment being processed but no order record being created, or a refund being completed but the customer’s screen still showing the payment as “completed.”"},{"question":"Does the 7-day right of withdrawal always apply to e-commerce in South Korea?","answer":"Generally, consumers may withdraw their purchase within 7 days from the date specified by law. However, exceptions may apply to digital content, custom-made products, and products that lose value through use; therefore, each case must be reviewed individually, including requirements for prior notice and consent."},{"question":"By when do I need to process the refund?","answer":"In the Korean e-commerce sector, merchants are required to refund payments within the statutory timeframe after a refund reason arises; in practice, it is safest to reflect a 3-business-day standard in the admin interface and notifications. Since delays may result in compensation claims, it is advisable to implement an automatic warning feature."},{"question":"What are the most common issues with partial refunds?","answer":"Issues frequently arise regarding order-wide coupons, free shipping requirements, return shipping costs, points used, and the allocation of discounts by product. To avoid having the administrator make a judgment call each time a refund request is received, rules—such as basing the calculation on the actual payment amount per product or using a proportional allocation method—should be established in advance."},{"question":"Can duplicate payments be prevented simply by disabling the button on the front end?","answer":"Disabling the button helps, but it is not enough. Since network retries, page refreshes, and duplicate webhook receipts may occur, server-side order locking, idempotency keys, unique transaction number constraints, and state-based validation are also required."},{"question":"What should be included in the payment failure notification message?","answer":"The message should include whether the payment was completed, the reason for the failure, whether the customer can try again, how long the order will remain active, and the order number needed for inquiries. Simply displaying a message stating that an error occurred will lead to increased customer churn and a rise in inquiries."},{"question":"Why is the payment history page required?","answer":"This is because customers need to be able to check for themselves when and how much they paid, as well as the status of any refunds. Without a payment history page, all verification requests will flood the customer service center, and customers may feel that the service is not properly managing the flow of funds."},{"question":"Is it sufficient for the refund policy to be listed only on the Terms and Conditions page?","answer":"That’s not enough. Customers must be able to easily find the refund period and restrictions near the product details, order form, and checkout button—where they make their purchasing decisions. Hiding refund policies or making the cancel button hard to find can lead to accusations of using dark patterns."},{"question":"What are the essential phrases to include in an AI prompt?","answer":"If there are any unspecified policies, it’s a good idea to include a statement asking the user to ask for clarification before writing any code. This statement serves as a safeguard that prompts the AI to ask about policies that are easy to overlook, such as refund approval procedures, criteria for deducting shipping costs, and exceptions to status transitions."},{"question":"What refund features are needed in the admin panel?","answer":"We need a refund waiting list, application date, processing deadline, upcoming deadline notifications, a preview of partial refund calculations, refund reasons, processor logs, and permission management. Since refunds are a recurring operational task, it is difficult to meet legal deadlines and maintain high-quality customer service if the administrator interface is inadequate."},{"question":"Do the same refund policies apply to digital content purchases?","answer":"Restrictions on the right to cancel a contract for digital content may become an issue depending on whether the content has been made available, whether prior notice was provided, and whether the customer gave consent. Therefore, these restrictions must be clearly communicated on the screen before payment, and the time of consent and the version of the terms and conditions must be recorded."}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"National Law Information Center: Act on Consumer Protection in Electronic Commerce, etc.","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"National Law Information Center: Enforcement Decree of the Act on Consumer Protection in Electronic Commerce, etc.","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe Docs: Idempotent Requests","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs: Payment Integration Workflow","type":"source"},{"url":"https://www.ftc.go.kr/","title":"Fair Trade Commission","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/ai-payment-feature-7-core-decisions"}