WO2023210852A1 - 결제 서비스 제공 방법 및 그 장치 - Google Patents

결제 서비스 제공 방법 및 그 장치 Download PDF

Info

Publication number
WO2023210852A1
WO2023210852A1 PCT/KR2022/006692 KR2022006692W WO2023210852A1 WO 2023210852 A1 WO2023210852 A1 WO 2023210852A1 KR 2022006692 W KR2022006692 W KR 2022006692W WO 2023210852 A1 WO2023210852 A1 WO 2023210852A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
order
information
status
state
Prior art date
Application number
PCT/KR2022/006692
Other languages
English (en)
French (fr)
Inventor
최하영
박윤미
한창환
비안치허
니우준
김아름
마치린
구민우
Original Assignee
쿠팡 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쿠팡 주식회사 filed Critical 쿠팡 주식회사
Publication of WO2023210852A1 publication Critical patent/WO2023210852A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G06Q10/0837—Return transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment

Definitions

  • This disclosure relates to a payment service providing method and device.
  • Such online payments require a stable payment service provision method.
  • a method of retrying payment is required to prevent customers from leaving.
  • the object of the present invention is to provide a payment service providing method and device for retrying payment in an asynchronous manner.
  • a method of providing a payment service by an electronic device includes: confirming a payment request for at least one item; Generating information about the order including order identification information in response to the confirmed payment request and checking the state of the circuit breaker; When executing asynchronous payment for a payment request based on the confirmed state of the circuit breaker, setting the payment state of the order to a first state; Storing information regarding payment of an order in a database in response to the payment status being set to a first status; Confirming payment-related information from a database and attempting to pay for an order corresponding to the payment-related information based on the payment-related information; Confirming whether payment of the order was successful; And when payment of the order is successful, it may include updating the payment status of the order to a second status.
  • the payment service providing method may further include transmitting a delivery request for at least one item corresponding to the order when the payment status of the order is set to the first status.
  • the payment service providing method includes, when payment of the order fails, updating the payment status of the order to a third status; And it may further include transmitting a request to cancel delivery of the order corresponding to the third status.
  • the method of providing payment services includes, when payment of an order fails, confirming the cause of payment failure, and providing the user with a page for requesting repayment for the order corresponding to the failed payment based on the confirmed cause of failure. may further include.
  • the payment service providing method includes the steps of providing a page containing information on changing the payment method for the order to the user when payment for the order fails; and attempting to pay for an order corresponding to the failed payment using the selected payment method, in response to a user's input for selecting a payment method through a page containing information about changing the payment method.
  • the state of the circuit breaker may be determined based on the payment failure rate for the order.
  • the circuit breaker has one of the following states: open, closed, and half-open, and the step of checking the state of the circuit breaker is that the circuit breaker is half-open.
  • the state it may include the step of confirming that asynchronous payment will be performed for one or more of the plurality of orders and confirming that synchronous payment will be performed for the remaining orders among the plurality of orders.
  • the circuit breaker transitions from a semi-open state to a closed state when the payment failure rate for orders during a preset period is lower than the preset payment failure rate, and when the payment failure rate during a preset period is higher than the preset payment failure rate. There can be a transition from the half-open state to the open state.
  • the payment service providing method may further include the step of reserving inventory for the item when the payment status of the order is set to the first status.
  • the payment service providing method may further include the step of applying a promotion when the payment status of the order is set to the first status and when the item is subject to promotion.
  • confirming the payment request may include requesting payment information from a payment module; And if payment information is received from the payment module as a result of the request, a page for requesting payment is provided to the user based on the received payment information, and if payment information is not received from the payment module as a result of the request, payment is made from the payment information database. It may include confirming information and providing a page to the user to request payment based on the confirmed payment information.
  • providing a page for requesting payment to a user may include confirming one or more payment methods from received payment information or confirmed payment information; And it may include providing a page containing information about changing a payment method including one or more payment methods to the user.
  • information about order payment may include one or more of order identification information, payment amount, information about payment method, information about at least one item, and information about delivery.
  • the electronic device may include a memory storing at least one program; and executing at least one program to confirm a payment request for at least one item, generate information about the order including order identification information in response to the confirmed payment request, and determine the state of the circuit breaker.
  • the payment status of the order is set to the first status
  • the payment status of the order is set to the first status.
  • Store information in a database check payment-related information from the database, attempt payment of the order corresponding to the payment-related information based on the payment-related information, confirm whether payment of the order was successful, and If payment is successful, it may include a processor that updates the payment status of the order to a second status.
  • the computer-readable recording medium may include a non-transitory recording medium on which a program for executing the above-described operation method on a computer is recorded.
  • the circuit breaker when the circuit breaker is in a half-open state, synchronous payment is attempted for some traffic, and asynchronous payment is attempted for some other traffic, making it possible to check whether payment is normalized while controlling the traffic being paid.
  • payment can be made by loading the payment method previously stored in the database.
  • FIG 1 shows an embodiment of an electronic device according to the present disclosure.
  • Figure 2 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 3 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • Figure 4 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • Figure 5 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 6 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 7 shows an embodiment of a user interface related to a payment service providing method according to the present disclosure.
  • Figure 8 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 9 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • Figure 10 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • Figure 11 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 12 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 13 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Figure 14 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • first, second, etc. used in this specification may be used to describe various components, but the components should not be limited by terms containing the ordinal numbers.
  • the above terms are used in context only to distinguish one element from another element in one part of the specification.
  • a first element may be referred to as a second element in other parts of the specification, and conversely, the second element may also be referred to as a first element in other parts of the specification. It can be.
  • FIG. 1 illustrates an example, simplified block diagram of an electronic device 100 that may be used to practice at least one embodiment of the present disclosure.
  • electronic device 100 may be used to implement any system or method described in this disclosure.
  • electronic device 100 may include any data server, web server, portable computing device, personal computer, tablet computer, workstation, mobile phone, smart phone, or any other device described below. It can be configured to be used as an electronic device.
  • Electronic device 100 may include memory 120 and one or more processors 110 having one or more cache memories and a memory controller that may be configured to communicate with memory 120 . Additionally, the electronic device 100 may be connected to the electronic device 100 through one or more ports (e.g., Universal Serial Bus (USB), headphone jack, Lightning connector, Thunderbolt connector, etc.). May include devices. A device that can be connected to electronic device 100 can include a plurality of ports configured to receive fiber optic connectors.
  • the configuration of electronic device 100 shown is intended as a specific example only for the purpose of illustrating preferred embodiments of the device. In the illustrated electronic device 100, only components related to the present embodiments are shown. Accordingly, it is obvious to those skilled in the art that the electronic device 100 may further include other general-purpose components in addition to the components shown.
  • Processor 110 may be used to cause electronic device 100 to provide the steps or functions of any embodiment described in this disclosure.
  • the processor 110 generally controls the electronic device 100 by executing programs stored in the memory 120 within the electronic device 100.
  • the processor 110 may be implemented as a central processing unit (CPU), a graphics processing unit (GPU), an application processor (AP), etc. provided in the electronic device 100, but is not limited thereto.
  • the memory 120 is hardware that stores various data processed within the electronic device 100.
  • the memory 120 can store data processed through the processor 110 and data to be processed in the electronic device 100. there is.
  • the memory 120 stores basic programming and data structures that can provide the functions of at least one embodiment of the present disclosure, as well as applications (programs, code modules) that can provide the functions of the embodiments of the present disclosure. , commands), drivers, etc. can be saved.
  • the memory 120 includes random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • RAM random access memory
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • the method and each step according to the present disclosure can be performed by the electronic device 100 or the processor 110, but for simplicity of explanation, the following assumes that the processor 110 is the one performing the method and each step according to the present disclosure. This explains.
  • FIG. 2 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • the processor 110 may confirm a payment request from the user. Specifically, the processor 110 may confirm a payment request for at least one item.
  • the payment request may include information about at least one item and information about the payment amount.
  • processor 110 may create an order. Specifically, processor 110 may generate information about the order including order identification information.
  • Order identification information refers to information for identifying different orders. For example, an identifier or order number for each order may be included in the order identification information.
  • the order or information about the order may include one or more of information about the orderer, information about at least one item, payment information, and delivery information.
  • the order or information about the order includes the orderer's identifier, orderer's name, orderer's address, name of the item, price of the item, quantity of the item, payment type, payment method, payment amount, delivery address, recipient, It may include one or more of shipping costs and shipping requests.
  • the processor 110 may check whether to perform asynchronous payment. Specifically, the processor 110 may check whether to perform asynchronous payment for the order. “Asynchronous payment” may mean that payment does not proceed immediately following the order, but occurs when a separate event is confirmed or a certain amount of time has passed after the order. In contrast, “synchronous payment” may mean that payment proceeds immediately following the order. For example, when payment failure for an order is expected to fail due to a payment system failure or synchronous payment for an order fails, the processor 110 does not execute synchronous payment immediately following the order, but confirms that asynchronous payment will be executed. You can.
  • the processor 110 may check the state of the circuit breaker and determine whether to perform asynchronous payment for the order based on the state of the circuit breaker. The operation of this circuit breaker and processor 110 will be described in detail later.
  • the processor 110 may attempt a synchronous payment.
  • the processor 110 may request payment from the payment module.
  • the payment module may be a physical device inside or outside the electronic device 100.
  • the electronic device 100 may be provided with a communication means capable of communicating with the payment module, and the processor 110 may transmit information to the payment module or receive information from the payment module using the communication means.
  • the payment module may be a program or instruction set stored in the memory 120.
  • the processor 110 may call an API (Application Programming Interface) or function so that the payment module executes payment.
  • API Application Programming Interface
  • the processor 110 may check whether payment has failed.
  • the processor 110 may check information about the payment result from the payment module.
  • Information about the payment result may include whether the payment was successful.
  • the processor 110 can check whether the payment was successful or failed by checking information about the payment result.
  • information about payment results may include information about the cause of payment failure when payment fails.
  • the processor 110 can confirm the cause of payment failure by checking information about the payment result, change the state of the circuit breaker based on the cause, or check whether to execute asynchronous payment for the next payment. there is.
  • the processor 110 may not be able to directly check whether payment has failed from the payment module.
  • the processor 110 may confirm payment failure if the payment module does not respond within a preset time.
  • the preset time may be set statically or dynamically depending on the characteristics of the electronic device 100 or the payment module, payment situation, or surrounding environment. More specifically, the processor 110 counts the number of times the payment module does not respond within a preset time, and may confirm payment failure if the number of times the payment module does not respond is more than a preset threshold number.
  • the preset threshold number of times may be set statically or dynamically depending on the characteristics of the electronic device 100 or the payment module, the payment situation, or the surrounding environment.
  • the processor 110 may request a response about the status of the payment module from the payment module, and if it confirms information from the payment module that the payment module is not normal, it may confirm payment failure.
  • the processor 110 may provide payment success information to the user or another device in step S261.
  • Payment success information may include one or more of information about the order such as order identification information, payment amount, payment method, and information about the item.
  • the processor 110 may provide payment success information to the user by displaying a page, message, or icon indicating that the payment was successful on a user interface displayed on a screen or an input/output device such as a screen.
  • the input/output device may be included in the electronic device 100 or may not be included in the electronic device 100.
  • the processor 110 may, according to step S260, place an order
  • the payment status of can be set to the first status.
  • the first state may correspond to the “attempting payment” state.
  • the processor 110 determines that the asynchronous payment will be executed as a result of step S230 or if the processor 110 determines that the payment has failed as a result of step S250, the processor 110 determines that it is attempting to pay for the order. Information can be provided to the user or to another device.
  • processor 110 may reserve inventory, apply promotions, and request delivery. In other words, the processor 110 may perform at least one of inventory reservation, promotion application, and delivery request.
  • the processor 110 may reserve inventory of the item to deliver the item. This has the advantage of providing the item to the user who ordered the item first even if the payment is made asynchronously. Additionally, this has the advantage that delivery time is not delayed compared to synchronous payment because delivery is carried out in advance even if payment is made asynchronously.
  • the processor 110 may apply the promotion. This has the advantage of preventing a situation where a promotion is applied in excess of the promotion budget because the promotion cost is deducted in advance from the limited promotion budget before the actual payment is made even if the payment is made asynchronously.
  • the processor 110 may request delivery of the item. Specifically, the processor 110 may transmit a request for delivery of an item to a retail department or a third-party seller. This has the advantage of providing the item to the user who ordered the item first even if the payment is made asynchronously. Additionally, this has the advantage that delivery time is not delayed compared to synchronous payment because delivery is carried out in advance even if payment is made asynchronously.
  • the processor 110 may store information regarding payment of an order in a database.
  • the database may be a physical or logical part of the memory 120, or may be a device that exists external to the electronic device 100. Since the processor 110 has already confirmed that asynchronous payment will be performed as a result of step S250, information regarding payment of the order may be information stored to attempt asynchronous payment at a later date.
  • information about order payment may include one or more of order identification information, payment amount, information about payment method, information about at least one item, and information about delivery.
  • information regarding the payment of an order may include payment service identifier, payment method, payment amount, payment amount currency unit, item payment amount, item name, item category identifier, item quantity, order number, order number, order It may include one or more of the following: time, buyer's identifier, shipping address, recipient's name, recipient's phone number, payment card identifier, withdrawal account identifier, and whether or not the payment will be made in installments.
  • information about order payment is not limited to the above, and any information that can be used for payment or asynchronous payment may be included in the information about order payment.
  • the processor 110 may store information regarding payment of an order in a database in response to the payment status being set to the first status. For example, in response to the payment status being set to “attempting payment,” the processor 110 may store information regarding payment of the order as information regarding asynchronous payment in the database.
  • Figure 3 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • processor 110 when it confirms that an asynchronous payment will be performed, it may provide information regarding purchase completion to the user. To this end, the processor 110 may display the purchase completion page 300 on the user interface displayed on the input/output device to provide information related to the purchase to the user.
  • the purchase completion page 300 may include one or more of the following information: expected delivery time, item name, recipient name, recipient address, recipient contact information, item payment amount, shipping cost, and payment amount. Additionally, in one embodiment, the purchase completion page 300 may include a guidance area 310.
  • the information area 310 may include information about payment errors and recovery, as well as information indicating that the order may be canceled in case of payment failure.
  • the guidance area 310 may include information that separate guidance may be provided in case of payment failure.
  • Figure 4 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • processor 110 confirms that asynchronous payment will be performed, it may provide detailed information about the order to the user. To this end, the processor 110 may display the order detail page 400 on a user interface displayed on the input/output device to provide detailed information related to the order to the user.
  • the order detail page 400 displays one or more of the following information: order date, order identification information (order number), item payment amount, shipping fee, payment amount, recipient name, recipient address, recipient contact information, expected delivery time, item name, and item quantity. may include.
  • the order details page 400 may include an item display area 420.
  • the order detail page 400 may include one or more item display areas 420, and each item display area 420 may display information about different items. You can.
  • the order details page 400 may include a payment status display area 421, and the payment status of the order may be displayed in the payment status display area.
  • information such as “attempting payment” (i.e., information indicating that payment is being attempted) may be displayed in the payment status display area 421. That is, when the processor 110 confirms that asynchronous payment will be executed as a result of step S230 shown in FIG. 2 or when the processor 110 confirms payment failure as a result of step S250, the processor 110 displays the payment status display area.
  • Information such as “attempting payment” may be displayed at 421 to provide information that payment for an order is being attempted to the user or another device. This has the advantage of letting the user know that an asynchronous payment is in progress.
  • Displaying payment attempt information such as “attempting payment” may be applied not only to the order detail page 400 but also to similar user interfaces.
  • a user interface such as an order list page, may also have a payment status display area for each order, and the processor 110 may determine the payment status corresponding to the order for which asynchronous payment was attempted according to step S620 during each order on the order list page.
  • Payment attempt information such as “Attempting payment” can also be displayed in the status display area.
  • order details page 400 may include a guidance area 410.
  • the information area 410 may include information about payment errors and recovery, as well as information indicating that the order may be canceled in case of payment failure.
  • the guidance area 410 may include information that separate guidance may be provided in case of payment failure.
  • Figure 5 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • the processor 110 may check the state of the circuit breaker and determine whether to perform asynchronous payment for the order based on the state of the circuit breaker. More specific details of this process are shown in Figure 5. That is, the steps shown in FIG. 5 may represent a specific embodiment of step S230 shown in FIG. 2. However, the embodiment of step S230 is not limited to the steps shown in FIG. 5.
  • the processor 110 can check the status of the circuit breaker.
  • the circuit breaker may be a program or instruction set stored in memory 120.
  • a circuit breaker can have either an open state or a closed state. In another embodiment, the circuit breaker may have any one of an open state, a closed state, and a half-open state.
  • FIG. 5 shows a flowchart showing operations performed by the processor 110 depending on the state of the circuit breaker, which can have any one of the open state, the closed state, and the half-open state.
  • the processor 110 may check whether the circuit breaker is in a closed state. If the circuit breaker is in the closed state, processor 110 may confirm that synchronous payment will be performed according to step S533.
  • the processor 110 may check whether the circuit breaker is in the half-open state. When the circuit breaker is in the half-open state, the processor 110 may confirm that asynchronous payment will be performed for one or more of the plurality of orders and may confirm that synchronous payment will be performed for the remaining orders of the plurality of orders.
  • the processor 110 may confirm that asynchronous payment will be performed for a number of orders corresponding to a preset ratio of the number of multiple orders, and may confirm that synchronous payment will be performed for the remaining orders among the plurality of orders.
  • the preset ratio may be 60%, and the number of multiple orders may be 100.
  • the processor 110 may confirm that asynchronous payment will be performed for 60 orders, or 60% of 100 orders, and synchronous payment may be performed for the remaining 40 orders out of 100 orders.
  • the preset rate may be set statically or dynamically depending on the amount of traffic, payment method, payment amount, payment time, or payment failure rate. This has the advantage of controlling the amount of traffic applied to the payment module and reducing the load by executing synchronous payment only for some of the multiple orders.
  • the processor 110 may confirm that synchronous payment will be performed for the number of orders corresponding to a preset ratio of the number of plural orders, and may also confirm that asynchronous payment will be performed for the remaining orders among the plurality of orders.
  • the preset ratio can be set statically or dynamically depending on the amount of traffic, payment method, payment amount, payment time, or payment failure rate.
  • the processor 110 determines to execute asynchronous payment for a number of orders corresponding to a preset first ratio of the number of plurality of orders, and determines to execute asynchronous payment at a preset second ratio of the number of plurality of orders. You can also confirm that synchronous payment will be made for the corresponding number of orders.
  • the preset first rate and the preset second rate may be set statically or dynamically according to the amount of traffic, payment method, payment amount, payment time, or payment failure rate.
  • step S534 determines that the circuit breaker is in the half-open state as a result of step S534. the processor 110 determines that the circuit breaker is in the open state and confirms that the asynchronous payment will be executed according to step S536. You can.
  • the processor 110 first checks whether the circuit breaker is in the closed state in step S532, and when it is confirmed that the circuit breaker is not in the closed state, the circuit breaker is half-open in step S534. Although it is shown to check whether the state is in the current state, the order of steps S532 and S534 may be reversed. That is, the processor 110 first checks whether the circuit breaker is in a half-open state, and when it is confirmed that the circuit breaker is not in a half-open state, it can check whether the circuit breaker is in a closed state.
  • the processor 110 may first check whether the circuit breaker is in the open state, and when it is confirmed that the circuit breaker is not in the open state, it may check whether the circuit breaker is in the semi-open state. Of course, the processor 110 may first check whether the circuit breaker is in the half-open state, and if it is confirmed that the circuit breaker is not in the half-open state, it may check whether the circuit breaker is in the open state.
  • the processor 110 may first check whether the circuit breaker is in the closed state, and when it is confirmed that the circuit breaker is not in the closed state, it may check whether the circuit breaker is in the open state. Of course, the processor 110 may first check whether the circuit breaker is in the open state, and if it is confirmed that the circuit breaker is not in the open state, it may check whether the circuit breaker is in the closed state.
  • the order of checking the status of the circuit breaker one by one to determine the status of the circuit breaker can be set statically or dynamically depending on the amount of traffic, payment method, payment amount, payment time, or payment failure rate. For example, if the payment failure rate is high, the probability of the circuit breaker being in the open state may be higher than the probability of being in the other two states. At this time, if you first check whether the circuit breaker is in the open state, you can confirm that the circuit breaker is in the open state with one check.
  • the processor 110 may first check whether the circuit breaker is in an open state.
  • the state of the circuit breaker may be determined by the user. However, in order to utilize the circuit breaker more efficiently, in one embodiment, the state of the circuit breaker may be determined based on the payment failure rate for the order.
  • the payment failure rate may refer to the failure rate of synchronous payment attempts. For example, if synchronous payment was attempted 100 times and 30 of them failed, the payment failure rate could be 30%.
  • the processor 110 may check the payment failure rate and determine the state of the circuit breaker based on the payment failure rate. This has the advantage that the processor 110 can induce normalization of the payment module by adjusting the amount of traffic or load applied to the payment module without directly checking the status of the payment module. Specifically, the processor 110 may check the payment failure rate for orders during a preset period and determine the state of the circuit breaker based on the payment failure rate.
  • the circuit breaker transitions from the semi-open state to the closed state when the payment failure rate for orders during a preset period is less than the preset payment failure rate, and the circuit breaker transitions from the semi-open state to the closed state, and the circuit breaker transitions from the semi-open state to the closed state when the payment failure rate for orders during a preset period is less than the preset payment failure rate.
  • the failure rate is greater than or equal to the failure rate, there may be a transition from the semi-open state to the open state.
  • the preset period or preset payment failure rate may be set statically or dynamically depending on the amount of traffic, payment method, payment amount, payment time, etc. For example, the preset period may be a value between 10 seconds and 100 seconds. Additionally, the preset payment failure rate may be 60% or close to it.
  • the circuit breaker transitions from a semi-open state to a closed state when the payment failure rate for orders during a preset period is less than or equal to the preset payment failure rate, and the payment failure rate for orders during a preset period exceeds the preset payment failure rate. In this case, there may be a transition from the semi-open state to the open state.
  • the state of the circuit breaker may be determined based on the payment success rate, and if the payment success rate for a preset period is less than the preset payment success rate, it transitions from the half-open state to the open state, and the state of the circuit breaker may be determined based on the payment success rate. If the payment success rate is higher than the preset payment success rate, the state may transition from the half-open state to the closed state. In another embodiment, when the payment success rate during a preset period is less than or equal to the preset payment success rate, the state transitions from the semi-open state to the open state, and when the payment success rate during the preset period is greater than the preset payment success rate, the semi-open state. It may transition to the closed state.
  • the processor 110 may check the payment failure rate for a preset number of payment attempts and determine the state of the circuit breaker based on the payment failure rate. For example, if 70 out of 200 payment attempts fail, the processor 110 may determine that the payment failure rate is 35% and determine the circuit breaker status based on this.
  • Payment attempts may include synchronous payment attempts, asynchronous payment attempts, or both. Additionally, the payment attempt may include a randomly generated test payment attempt to check the status of the payment module, regardless of the actual payment attempt according to the user's payment request.
  • the processor 110 may check the status of a plurality of circuit breakers and determine whether to perform asynchronous payment based on the status of the plurality of circuit breakers.
  • Each of the multiple circuit breakers may relate to the failure of a different task, process, step, algorithm, function, module, or API.
  • the state of the first circuit breaker may be determined according to the call failure rate of the payment window API
  • the state of the second circuit breaker may be determined according to the failure rate of the payment pre-operation.
  • the processor 110 may determine to execute synchronous payment when both the first circuit breaker and the second circuit breaker are in a closed state.
  • the processor 110 may determine to execute asynchronous payment when one of the first circuit breaker or the second circuit breaker is in an open state.
  • the circuit breaker may transition from the closed state to the open state when the payment failure rate for orders during a preset period exceeds the preset payment failure rate. For example, if the payment failure rate for 20 seconds exceeds 60%, the circuit breaker may transition from the closed state to the open state.
  • the circuit breaker may transition from the open state to the half-open state when a preset time elapses. For example, if 20 seconds have passed since the circuit breaker transitions to the open state, the circuit breaker may transition from the open state to the semi-open state. In this way, instead of transitioning the circuit breaker from the open state to the closed state immediately, transitioning the circuit breaker from the open state to the semi-open state gradually increases the execution rate of synchronous payment, thereby placing only a small amount of traffic or load on the payment module. It has the advantage of being able to check whether the payment module has been normalized at the same time as charging.
  • Figure 6 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • the steps shown in FIG. 6 may be executed subsequent to the steps shown in FIG. 2, but the present disclosure is not limited thereto.
  • the steps shown in FIG. 6 may be executed after the steps shown in FIG. 2 have been executed multiple times for a plurality of different orders.
  • the processor 110 may check information about one or more payments from the database in step S610.
  • Information about payment may include information about payment of an order to perform asynchronous payment.
  • the information about payment may include information about payment of the order stored in the database according to step S270 of FIG. 2.
  • each of the information about one or more payments is information about the payment of a plurality of orders stored in the database according to step S270, where the steps shown in FIG. 2 are executed multiple times for a plurality of different orders and executed multiple times. It can be included. In this way, information about order payment is stored in the database, and it may take several seconds, minutes, or dozens of minutes for the stored payment information to be confirmed.
  • the processor 110 may attempt to pay for an order corresponding to one or more pieces of payment-related information in step S620.
  • a payment attempt for an order corresponding to an asynchronous payment may mean going through the same process as a synchronous payment attempt.
  • a payment attempt for an order corresponding to an asynchronous payment is conceptually or temporally distinct from a synchronous payment attempt immediately following the order. do.
  • the processor 110 may attempt to pay for an order corresponding to one or more pieces of payment-related information based on the payment failure rate. For example, if the payment failure rate is less than or equal to a preset value, the processor 110 may attempt to pay for an order corresponding to one or more pieces of payment-related information. This has the advantage of lowering the probability of payment failure even if payment is attempted for an order corresponding to one or more pieces of payment-related information.
  • the payment failure rate may mean the failure rate of a synchronous payment attempt, an asynchronous payment attempt, a test payment attempt, or a combination thereof.
  • the processor 110 may check whether the payment was successful or failed. When the processor 110 confirms that the payment has not failed, the processor 110 may update the payment status to the second status in step S641. In other words, if payment of the order fails, the processor 110 may update the payment status of the order corresponding to the payment to the second status. The second status may correspond to “payment success.” For example, as a result of step S230 shown in FIG. 2, the processor 110 confirms that the asynchronous payment will be executed, or as a result of step S250, the processor 110 confirms payment failure, and the processor 110 determines that the payment will be performed asynchronously.
  • step S641 the processor 110 displays “Payment successful” or “Payment completed” in the payment status display area 421. information can be displayed. Also in this case, the processor 110 may remove the guidance area 410 from the order details page 400 .
  • the payment status of the order may correspond to the first status, and if subsequent payment is successful, the payment status of the order may correspond to the second status, and if subsequent payment fails, the payment status of the order may correspond to the first status.
  • the payment status of the order may be described as corresponding to the third status.
  • Displaying payment success information such as “payment successful” or “payment completed” or removing the information area may be applied not only to the order details page 400 but also to similar user interfaces.
  • a user interface such as an order list page, may also have a payment status display area for each order, and the processor 110 may determine the payment status corresponding to the order for which asynchronous payment was attempted according to step S620 during each order on the order list page.
  • Payment success information such as “payment successful” or “payment completed” can be displayed in the status display area.
  • step S640 the processor 110 may update the payment status of the order corresponding to the failed payment to a third state.
  • the processor 110 may update the payment status of the order corresponding to the payment to a third status.
  • the third state may correspond to “payment failure.”
  • the processor 110 confirms that the asynchronous payment will be executed, or as a result of step S250, the processor 110 confirms payment failure, and the processor 110 determines that the payment will be performed asynchronously.
  • the processor 110 displays “Payment failure” or “Order cancellation” in the payment status display area 421. information can be displayed. Also, in this case, the processor 110 may update the information area 410 from the order details page 400 to display information about payment failure.
  • Displaying payment failure information such as “payment failure” or “order cancellation” or updating the information area may be applied not only to the order details page 400 but also to similar user interfaces.
  • a user interface such as an order list page, may also have a payment status display area for each order, and the processor 110 may determine the payment status corresponding to the order for which asynchronous payment was attempted according to step S620 during each order on the order list page.
  • Payment failure information such as “payment failed” or “order canceled” can be displayed in the status display area.
  • step S650 the processor 110 may cancel the order corresponding to the third state, and in step S660, may transmit a delivery cancellation request for the order corresponding to the third state. That is, if payment of an order fails during a payment attempt, the processor 110 may cancel the order corresponding to the failed payment and transmit a delivery cancellation request.
  • the order corresponding to the failed payment may include the order created in step S220 of FIG. 2. Additionally, the delivery cancellation request may correspond to the delivery requested in step S270 of FIG. 2.
  • the processor 110 determines the cause of payment failure when payment of an order fails, and provides the user with a page for requesting repayment for the order corresponding to the failed payment based on the confirmed cause of failure. You can. For example, if the cause of the failure is insufficient account balance, the processor 110 may provide the user with information that the account balance is insufficient and induce the user to make a deposit. Afterwards, the processor 110 may provide the user with a page to request repayment for the order. This has the effect of encouraging users to retry payment for items despite payment failure.
  • the page for requesting repayment for an order may be a checkout page. In this way, if payment for an order fails, a checkout page can be provided to the user to request repayment using another payment method.
  • the processor 110 provides the user with a page containing information about changing the payment method of the order corresponding to the payment when payment of the order fails, and provides a page containing information about changing the payment method.
  • payment of an order corresponding to a failed payment may be attempted using the selected payment method.
  • the processor 110 may provide the user with a page containing information about changing payment methods, including payment methods such as account transfer and card payment.
  • a page containing information about changing the payment method may be a payment method selection page. The user may select card payment as a payment method, and the processor 110 may attempt to pay for the order corresponding to the failed payment through card payment. At this time, the processor 110 may limit the selection of payment methods used for failed payments.
  • processor 110 may shade or not display the corresponding area so that the user cannot select bank transfer as the payment method on the payment method selection page. there is. This has the advantage of encouraging users to conveniently retry payment even if payment fails.
  • FIG. 7 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure.
  • the notification pages 700a and 700b may include order list display areas 710a and 710b and result display areas 711a and 711b for orders.
  • the result display areas 711a and 711b may display order results or payment results for each order in the order list display areas 710a and 710b.
  • step S630 if the processor 110 confirms that the payment of the order corresponding to the payment information has not failed, the processor 110 may indicate “payment successful” or “payment complete.” Payment success information, such as such, can be displayed in the result display area 711a of the notification page 700a. In addition, in one embodiment, when the processor 110 confirms that payment of the order corresponding to the payment information has failed according to the result of step S630, the processor 110 may perform an operation such as “order cancellation” or “payment failure.” Payment failure information may be displayed in the result display area 711b of the notification page 700b. This has the advantage of notifying users who have left the payment window that the status of asynchronous payment has been updated.
  • the processor 110 when the processor 110 confirms that payment of the order corresponding to the payment information has failed according to the result of step S630, the processor 110 displays the failed payment in the order list display area 710b.
  • a re-add to shopping cart button 712b may be displayed in the area corresponding to the corresponding order. This has the advantage of allowing users to more conveniently repay for items included in their order.
  • the processor 110 when the processor 110 confirms that the payment of the order corresponding to the payment information has failed according to the result of step S630, the processor 110 pays the user a point or a discount coupon and orders the user.
  • a phrase indicating that points or discount coupons have been paid to the user may be displayed in the area corresponding to the order corresponding to the failed payment. This has the advantage of encouraging users to repay for items included in their order.
  • Figure 8 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • the processor 110 may request payment information from the payment module.
  • Payment information may include information necessary for payment or payment, such as payment method, payment bank, recent payment method, card type, and account information.
  • the processor 110 may check whether payment information has been received from the payment module.
  • the processor 110 receives payment information from the payment module, in step S831, the processor 110 provides the user with a page for requesting payment based on the received payment information, and provides payment information from the payment module. If not received, in step S832, the processor 110 verifies the payment information from the payment information database, and in step S832, the processor 110 creates a page for requesting payment based on the confirmed payment information. It can be provided to the user. This means that even if payment information cannot be properly provided to the processor 110 because the payment module does not operate normally, payment can be made by providing the user with a page to request payment using payment information previously backed up in the payment information database instead. There is an advantage.
  • the page for requesting payment may be a checkout page.
  • the checkout page may include information such as the name and quantity of the item to be ordered, the payment amount for the item, shipping cost, payment amount, and payment method.
  • the checkout page may include an input interface such as a payment button, and in response to the user manipulating an input interface such as a payment button, the processor 110 may confirm a payment request for the item to be ordered.
  • the checkout page may include an input interface such as a button for changing the payment method.
  • the processor 110 may create a payment method selection page where a payment method can be changed or added. Specifically, the processor 110 verifies one or more payment methods from the payment information received from the payment module or payment information confirmed from the payment information database, and includes information about a change in the payment method including one or more payment methods.
  • the page can be provided to the user.
  • Figure 9 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure. Specifically, Figure 9 shows one embodiment of the payment method selection page 900.
  • the payment method selection page 900 may include a list of payment methods. Payment methods included in the list may be displayed in payment method display areas 920a, 920b, 920c, 920d, and 920e, respectively.
  • the checkout page or payment method selection page may include information about the unavailable payment method.
  • the processor 110 may display the payment method display areas 920c, 920d, and 920e corresponding to payment methods that cannot be used on the payment method selection page 900 in gray shading. there is.
  • the processor may limit the selection of payment methods corresponding to the payment method display areas 920c, 920d, and 920e.
  • the payment method selection page 900 may include a guidance area 910 that includes a notice indicating that some payment methods cannot be used.
  • the payment method display areas 920a, 920b, 920c, 920d, and 920e may include a payment method selection button 921. The user can select the payment method to use by pressing the payment method selection button 921.
  • the payment method display areas 920a, 920b, 920c, 920d, and 920e may include a detailed payment method display area 922 for each payment method.
  • the payment method “account transfer” may be displayed in the payment method display area 920a.
  • the name of a bank that allows account transfer may be displayed in the payment detail method display area 922.
  • the payment method display areas 920a, 920b, 920c, 920d, and 920e may include a selection completion button 924. The user can confirm the selection of the payment method and detailed payment method by pressing the selection completion button 924.
  • the payment method display area (920a, 920b, 920c, 920d, 920e) may include a payment method change button 923.
  • the user can change the payment detailed method by pressing the change payment detailed method button 923.
  • Figure 10 shows an embodiment of a user interface related to a payment service provision method according to the present disclosure. Specifically, Figure 10 shows a payment detail method change page 1000. When the user presses the change payment detailed method button 923, the change payment detailed method page 1000 may be displayed.
  • the detailed payment method change page 1000 may include a list of detailed payment methods. Each detailed payment method included in the list may be displayed in the detailed payment method display areas 1010a, 1010b, 1010c, 1010d, and 1010e, respectively.
  • the detailed payment method display area (1010a, 1010b, 1010c, 1010d, 1010e) may include a detailed payment method selection button 1011. The user can select the detailed payment method to be used by pressing the payment detailed method selection button 1011.
  • FIG 11 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • processor 110 may generate 1110 a 1-click purchase page.
  • the 1-click purchase page can be a simplified checkout page that allows you to pay for an order without a separate payment authentication process.
  • the processor 110 may request payment information from the payment module 1113. If the processor 110 fails to receive payment information from the payment module 1113 (i.e., fails to load payment information), a general checkout page may be provided (1111). The checkout page may be a page for requesting payment.
  • the processor 110 may request payment information from the payment information provider 1112.
  • the payment information provider 1112 may be a program or instruction set stored in the memory 120.
  • the payment information provider 1112 may receive a request for payment information from the processor 110 and request payment information from the payment module. If the payment information provider 1112 fails to receive payment information from the payment module 1113, the payment information provider 1112 may check the payment information from the payment information database 1114.
  • the payment information provider 1112 may transmit payment information to the processor 110.
  • the processor 110 may provide the user with a page for requesting payment based on payment information received from the payment information provider 1112.
  • the processor 110 may create an order (1121) when the user clicks (1120) a purchase button through the checkout page.
  • An order may include order identification information.
  • the processor 110 may perform pre-payment work and load the payment window (1122).
  • Payment pre-operations may include storing order information (item, payment method, payment amount, etc.) and verifying a token to load the payment window. Synchronous payment can be executed through the loaded payment window.
  • the processor 110 may request asynchronous payment (1123). Requesting 1123 an asynchronous payment may include confirming that an asynchronous payment will be performed. Processor 110 may then reserve inventory (1124) and apply promotions (1125). Additionally, the processor 110 may check the payment status as a payment attempt according to the asynchronous payment request 1123. Information regarding the confirmed payment status (payment attempt in progress) may be provided to the user through an input/output device.
  • the processor 110 may store information about order payment in the asynchronous payment consumer 1126 according to the asynchronous payment request 1123.
  • the asynchronous payment consumer 1126 may include or be included in a database that can store information about order payment. Orders may include orders that have failed to settle or orders for which synchronous settlement has not occurred due to a circuit breaker being open.
  • the processor 110 requests delivery of the item to the retail department 1132 (1133), requests delivery of the item to a third-party seller 1134, or travels. Payment for the product 1135 can be completed.
  • the processor 110 may check information about one or more payments from the asynchronous payment consumer 1126 or the database and process the asynchronous payment (1127). In other words, the processor 110 checks information about one or more payments from the asynchronous payment consumer 1126 or the database, and attempts to settle the order corresponding to each of the one or more payment information based on the payment information (You can request payment to the payment module (1128) and check whether payment of the order was successful.
  • the processor 110 may update the payment result (1129). For example, if payment is successful, the processor 110 may update the payment status to the second status. For another example, when payment fails, the processor 110 may update the payment status to a third status. Information about the updated payment status may be provided to the user through an input/output device.
  • the processor 110 may receive cancellation or return (1130). That is, the processor 110 may cancel the order corresponding to the failed payment (1131) and, if delivery according to the order has already occurred, request to proceed with the return procedure.
  • Processor 110 may request suspension of delivery 1133 if the item is being prepared for delivery 1133 by the retail department 1132 or if delivery 1133 is already in progress. Additionally, the processor 110 may request delivery or cancellation of the order and return of the item to the third-party seller 1134. Additionally, the processor 110 may cancel payment for the travel product 1135 for which payment has been completed.
  • FIG. 12 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Traffic controller 1212, payment method selection page traffic controller 1215, and asynchronous payment traffic controller 1218 shown in FIG. 12 can have any of states A, B, or C (traffic controller 1212 is in state C). cannot have), the processor 110 may proceed with the following procedures (following the appropriate arrows) depending on the status of the traffic controller 1212, the payment method selection page traffic controller 1215, and the asynchronous payment traffic controller 1218. .
  • the states of the traffic controller 1212, the payment method selection page traffic controller 1215, and the asynchronous payment traffic controller 1218 may be preset or changed by the user, the processor 110, or another device.
  • an embodiment of the payment service providing method according to the present disclosure may not include all of the traffic controller 1212, the payment method selection page traffic controller 1215, and the asynchronous payment traffic controller 1218.
  • the traffic controller 1212, the payment method selection page traffic controller 1215, and the asynchronous payment traffic controller 1218 can all be replaced with arrows corresponding to each B state. That is, arrows entering the traffic controller 1212, the payment method selection page traffic controller 1215, and the asynchronous payment traffic controller 1218 may be directly connected to the arrows corresponding to each B state.
  • the processor 110 may call the payment information API (1211) to provide a checkout page (1210).
  • the processor 110 requests payment to the payment module (1213), and when the traffic controller 1212 is in state B, it can load payment information (1214). .
  • the processor 110 may request payment information from the payment module to load the payment information (1214). If loading 1214 of payment information fails, the processor 110 may use simplified payment method selection page data 1221 as payment information. For example, the processor 110 may check payment information, such as the latest payment method, from the database.
  • the processor 110 may activate 1222 a simplified payment method selection page.
  • the simplified payment method selection page may include a user interface that restricts the user from selecting an unusable payment method, or may be a page in which the user interface corresponding to the unusable payment method is removed.
  • the processor 110 may check the state 1216 of the payment method selection page circuit breaker. When the payment method selection page circuit breaker state 1216 is in the open state, the processor 110 may activate a simplified payment method selection page 1222. Additionally, if the state of the payment method selection page circuit breaker 1216 is not in the open state or the state of the payment method selection page traffic controller 1215 is in the A state, the processor 110 determines whether the order is eligible (1217). )can do.
  • the applicable target may mean an order in which asynchronous payment can be executed.
  • the applicable target is an order by a user who has activated one-touch payment (a payment in which payment is made immediately without a separate authentication process when touching the payment button), and an order where the payment method is the service provider's own payment service or self-financial service according to this disclosure.
  • orders where the payment amount is less than or equal to a preset amount may be included.
  • orders such as gift card orders, electronic gift (E-gift) orders, subscription orders, and travel product orders may not be eligible for application.
  • orders using points accumulated for the service provider's services may not be eligible for application.
  • processor 110 may check the status of asynchronous payment traffic controller 1218. When the state of the asynchronous payment traffic controller 1218 is in the B state, the processor 110 may check the state 1219 of the asynchronous payment circuit breaker.
  • the processor 110 may disable the use of the savings.
  • the processor 110 blocks According to (1220), using the simplified payment method selection page data (1221), the simplified payment method selection page can be activated (1222) and the use of accumulated points can be deactivated (1223).
  • FIG. 13 shows a flowchart of an embodiment of a payment service providing method according to the present disclosure.
  • Traffic controller 1312 and asynchronous payment traffic controller 1317 shown in FIG. 13 can have either A, B, or C states (traffic controller 1312 cannot have C state), and processor 110 Depending on the status of the traffic controller 1312 and the asynchronous payment traffic controller 1317 (following the appropriate arrows), the following procedures may be performed.
  • the states of the traffic controller 1312 and the asynchronous payment traffic controller 1317 may be preset or changed by the user, the processor 110, or another device.
  • an embodiment of the payment service providing method according to the present disclosure may not include both the traffic controller 1312 and the asynchronous payment traffic controller 1317.
  • both the traffic controller 1312 and the asynchronous payment traffic controller 1317 can be replaced with arrows corresponding to each B state. That is, the arrows entering the traffic controller 1312 and the asynchronous payment traffic controller 1317 may be directly connected to the arrows corresponding to each B state.
  • the processor 110 may create an order (1311) in response to the user's click on the payment button (1310). If the state of the traffic controller 1312 is in the B state, the processor 110 may check (1316) whether the generated order is applicable.
  • the subject of application may mean the same concept as the subject of application mentioned in the above description of FIG. 12.
  • processor 11 may check the status of asynchronous payment traffic controller 1317 if the order is eligible.
  • the processor 110 may check the state 1318 of the payment window circuit breaker.
  • the state 1318 of the payment window circuit breaker may be determined according to the failure rate of loading the payment window.
  • the processor 110 may check the state 1319 of the payment pre-operation circuit breaker.
  • the state 1319 of the payment pre-task circuit breaker may be determined according to the failure rate of the payment pre-task.
  • the state of the traffic controller 1312 is in state A
  • the created order is not eligible
  • the state of the asynchronous payment traffic controller 1317 is in state A
  • the state of the payment pre-operation circuit breaker 1319 is in the closed state or the half-open state
  • the processor 110 may call the payment pre-operation and check whether it was successful (1313).
  • Payment pre-operations may include storing order information (item, payment method, payment amount, etc.) and verifying a token to load the payment window.
  • processor 110 may open a payment window (1314).
  • the payment window is displayed on the user interface of the input/output device, and payment can be made in response to the user's input through the payment window.
  • processor 110 may confirm 1315 the failure of the order.
  • the processor 110 may check (1320) whether the accumulated funds are used. If the accumulated funds are used, the processor 110 may confirm (1322) the failure of the order. If the accumulated funds are not used, the processor 110 may proceed with asynchronous payment (1321). That is, the processor 110 can confirm that asynchronous payment will be performed for the created order.
  • FIG. 14 shows a method of operating the electronic device 100 according to an embodiment. Since each step of the operation method of FIG. 14 can be performed by the electronic device 100 of FIG. 1, description of content that overlaps with FIG. 1 will be omitted.
  • step S1410 the electronic device 100 may confirm a payment request for at least one item.
  • the electronic device 100 requests payment information from the payment module, and when payment information is received from the payment module as a result of the request, provides the user with a page for requesting payment based on the received payment information, and makes payment as a result of the request. If payment information is not received from the module, the payment information may be confirmed from the payment information database, and a page for requesting payment based on the confirmed payment information may be provided to the user.
  • the electronic device 100 may confirm one or more payment methods from the received or confirmed payment information and provide the user with a page containing information about changing the payment method that includes one or more payment methods.
  • step S1420 the electronic device 100 may generate information about the order including order identification information in response to the confirmed payment request and check the state of the circuit breaker.
  • the state of the circuit breaker may be determined based on the payment failure rate for the order.
  • a circuit breaker may have any of the following states: open, closed, and half-open.
  • the electronic device 100 may confirm that asynchronous payment will be performed for one or more of the plurality of orders and may confirm that synchronous payment will be performed for the remaining orders of the plurality of orders. .
  • the circuit breaker transitions from a semi-open state to a closed state when the payment failure rate for orders during a preset period is lower than the preset payment failure rate, and when the payment failure rate for orders during a preset period is higher than the preset payment failure rate. In this case, there may be a transition from the half-open state to the open state.
  • step S1430 when performing asynchronous payment for a payment request based on the confirmed state of the circuit breaker, the electronic device 100 may set the payment state of the order to the first state.
  • the electronic device 100 may transmit a delivery request for at least one item corresponding to the order.
  • the electronic device 100 may reserve inventory for an item when the payment status of the order is set to the first status.
  • the electronic device 100 may apply a promotion when the payment status of the order is set to the first status and when the item is subject to promotion.
  • step S1440 the electronic device 100 may store information regarding payment of the order in a database in response to the payment status being set to the first status.
  • Information about order payment may include one or more of order identification information, payment amount, information about payment method, information about at least one item, and information about delivery.
  • step S1450 the electronic device 100 may check payment-related information from the database and attempt to pay for the order corresponding to the payment-related information based on the payment-related information.
  • step S1460 the electronic device 100 may check whether payment for the order was successful.
  • step S1470 when payment of the order is successful, the electronic device 100 may update the payment status of the order to the second status.
  • the electronic device 100 may update the payment status of the order to a third status and transmit a request to cancel delivery of the order corresponding to the third status.
  • the electronic device 100 may check the cause of payment failure and provide the user with a page for requesting repayment for the order corresponding to the failed payment based on the confirmed cause of failure. .
  • the electronic device 100 When payment of an order fails, the electronic device 100 provides the user with a page containing information about changing the payment method for the order, and selects a payment method through the page containing information about changing the payment method. In response to the user's input, payment of the order corresponding to the failed payment may be attempted using the selected payment method.
  • Embodiments according to the present disclosure described above may be implemented in the form of program instructions that can be executed through various computer components and recorded on a computer-readable recording medium or non-transitory recording medium.
  • the computer-readable recording medium or non-transitory recording medium may include program instructions, data files, data structures, etc., singly or in combination.
  • Program instructions recorded on the computer-readable recording medium or non-transitory recording medium may be specially designed and constructed for the present invention or may be known and usable by those skilled in the computer software field.
  • Examples of computer-readable recording media or non-transitory recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROMs and DVDs, and magneto-optical media such as floptical disks.
  • magneto-optical media and hardware devices specifically configured to store and perform program instructions, such as ROM, RAM, flash memory, etc.
  • program instructions include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • the hardware device or electronic device may be configured to operate as one or more software modules to perform processing according to the present disclosure, and vice versa.
  • This embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented as various numbers of hardware, software, or combinations thereof that execute specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc. that can execute various functions under the control of one or more microprocessors or other control devices. can be hired. Similar to how the components can be implemented as software programming or software elements, the present embodiments include various algorithms implemented as combinations of data structures, processes, routines or other programming constructs, such as C, C++, Java ( It can be implemented in a programming or scripting language such as Java), assembler, etc. Functional aspects may be implemented as algorithms running on one or more processors. Additionally, this embodiment may employ conventional technologies for electronic environment setting, signal processing, data processing, or a combination thereof.

Abstract

적어도 하나의 아이템에 대한 결제 요청을 확인하고, 확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하고, 상기 확인된 서킷브레이커의 상태에 기초하여 상기 결제 요청에 대한 비동기 결제를 실행할 경우, 상기 주문의 결제 상태를 제1 상태로 설정하고, 상기 결제 상태가 제1 상태로 설정된 것에 대응하여 상기 주문의 결제에 관한 정보를 데이터베이스에 저장하고, 상기 데이터베이스로부터 결제에 관한 정보를 확인하고, 상기 결제에 관한 정보를 기초로 상기 결제에 관한 정보에 대응되는 주문의 결제를 시도하고, 상기 주문의 결제의 성공 여부를 확인하고, 상기 주문의 결제에 성공한 경우, 상기 주문의 결제 상태를 제2 상태로 갱신하는 전자 장치 및 그의 동작 방법을 제공한다.

Description

결제 서비스 제공 방법 및 그 장치
본 개시는 결제 서비스 제공 방법 및 그 장치에 관한 것이다.
정보통신기술의 발전에 따라 전자상거래 시장은 빠르게 발전하여 쇼핑의 한 분야로 자리잡았다. 고객은 전자 기기 등을 사용하여 온라인 상에서 물품을 구매하고, 원하는 장소로 물품을 배달시킬 수 있다. 이에 따라 판매자와 구매자 간의 매매를 중개하고 배송 서비스를 배송하는 매매 중개 서비스가 활성화되고 있다.
이러한 온라인 결제에는 안정적인 결제 서비스 제공 방법이 요구된다. 특히, 결제 서비스에 트래픽이 몰리는 등의 사유로 인하여 결제 서비스에 문제가 생긴 경우, 고객의 이탈을 방지하기 위하여 결제를 재시도하는 방안이 요구된다.
본 발명의 과제는 결제를 비동기 방식으로 재시도하는 결제 서비스 제공 방법 및 그 장치를 제공하는데 있다.
본 발명이 이루고자 하는 기술적 과제는 상기된 바와 같은 과제로 한정되지 않으며, 이하의 실시예들로부터 또 다른 기술적 과제들이 유추될 수 있다.
일 실시예에 따라, 전자 장치의 결제 서비스 제공 방법은, 적어도 하나의 아이템에 대한 결제 요청을 확인하는 단계; 확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하는 단계; 확인된 서킷브레이커의 상태에 기초하여 결제 요청에 대한 비동기 결제를 실행할 경우, 주문의 결제 상태를 제1 상태로 설정하는 단계; 결제 상태가 제1 상태로 설정된 것에 대응하여 주문의 결제에 관한 정보를 데이터베이스에 저장하는 단계; 데이터베이스로부터 결제에 관한 정보를 확인하고, 결제에 관한 정보를 기초로 결제에 관한 정보에 대응되는 주문의 결제를 시도하는 단계; 주문의 결제의 성공 여부를 확인하는 단계; 및 주문의 결제에 성공한 경우, 주문의 결제 상태를 제2 상태로 갱신하는 단계를 포함할 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제 상태가 제1 상태로 설정된 경우, 주문에 대응하는 적어도 하나의 아이템에 대한 배송 요청을 전송하는 단계를 더 포함할 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제가 실패한 경우, 주문의 결제 상태를 제3 상태로 갱신하는 단계; 및 제3 상태에 대응하는 주문의 배송 취소 요청을 전송하는 단계를 더 포함할 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제가 실패한 경우, 결제의 실패 원인을 확인하고, 확인된 실패 원인을 기초로 실패한 결제에 대응하는 주문에 대한 재결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계를 더 포함할 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제가 실패한 경우, 주문에 대한 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하는 단계; 및 결제 수단 변경에 대한 정보를 포함하는 페이지를 통해 결제 수단을 선택하는 사용자의 입력에 대응하여, 선택된 결제 수단을 사용하여 실패한 결제에 대응하는 주문의 결제를 시도하는 단계를 더 포함할 수 있다.
또한, 서킷브레이커의 상태는 주문에 대한 결제 실패율에 기초하여 결정될 수 있다.
또한, 서킷브레이커는 열림(open) 상태, 닫힘(closed) 상태 및 반-열림(half-open) 상태 중 어느 하나의 상태를 가지고, 서킷브레이커의 상태를 확인하는 단계는, 서킷브레이커가 반-열림 상태에 있는 경우, 복수의 주문 중 하나 이상에 대해 비동기 결제를 실행할 것으로 확인하고, 복수의 주문 중 나머지 주문에 대해 동기 결제를 실행할 것으로 확인하는 단계를 포함할 수 있다.
또한, 서킷브레이커는, 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율보다 낮은 경우 반-열림 상태에서 닫힘 상태로 천이되고, 기 설정된 기간 동안의 결제 실패율이 기 설정된 결제 실패율보다 높은 경우 반-열림 상태에서 열림 상태로 천이될 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제 상태가 제1 상태로 설정된 경우, 아이템에 대한 재고를 예약하는 단계를 더 포함할 수 있다.
또한, 결제 서비스 제공 방법은, 주문의 결제 상태가 제1 상태로 설정된 경우, 아이템이 프로모션 대상인 경우, 프로모션을 적용하는 단계를 더 포함할 수 있다.
또한, 결제 요청을 확인하는 단계는, 결제 모듈로 결제 정보를 요청하는 단계; 및 요청 결과 결제 모듈로부터 결제 정보를 수신한 경우, 수신된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하고, 요청 결과 결제 모듈로부터 결제 정보를 수신하지 못한 경우, 결제 정보 데이터베이스로부터 결제 정보를 확인하고, 확인된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계를 포함할 수 있다.
또한, 결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계는, 수신된 결제 정보 또는 확인된 결제 정보로부터 하나 이상의 결제 수단을 확인하는 단계; 및 하나 이상의 결제 수단이 포함된 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하는 단계를 포함할 수 있다.
또한, 주문의 결제에 관한 정보는, 주문 식별 정보, 결제 금액, 결제 수단에 관한 정보, 적어도 하나의 아이템에 관한 정보, 배송에 관한 정보 중 하나 이상을 포함할 수 있다.
또한, 전자 장치는, 적어도 하나의 프로그램이 저장된 메모리; 및 적어도 하나의 프로그램을 실행함으로써, 적어도 하나의 아이템에 대한 결제 요청을 확인하고, 확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하고, 확인된 서킷브레이커의 상태에 기초하여 결제 요청에 대한 비동기 결제를 실행할 경우, 주문의 결제 상태를 제1 상태로 설정하고, 결제 상태가 제1 상태로 설정된 것에 대응하여 주문의 결제에 관한 정보를 데이터베이스에 저장하고, 데이터베이스로부터 결제에 관한 정보를 확인하고, 결제에 관한 정보를 기초로 결제에 관한 정보에 대응되는 주문의 결제를 시도하고, 주문의 결제의 성공 여부를 확인하고, 주문의 결제에 성공한 경우, 주문의 결제 상태를 제2 상태로 갱신하는 프로세서를 포함할 수 있다.
또한, 컴퓨터로 읽을 수 있는 기록매체는, 상술한 동작 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 비일시적 기록매체를 포함할 수 있다
기타 실시예들의 구체적인 사항은 상세한 설명 및 도면들에 포함된다.
본 발명에 따르면, 결제 시스템에 문제가 생긴 경우 결제를 비동기 방식으로 진행하여 결제 시스템이 이내 정상화 되었을 때 결제를 재시도할 수 있다. 이는
본 발명에 따르면, 서킷브레이커가 반-열림 상태에 있는 경우 일부 트래픽에 대해서 동기 결제가 시도되고, 다른 일부 트래픽에 대해서는 비동기 결제가 시도되어 결제되는 트래픽을 조절하면서도 결제의 정상화 여부를 확인할 수 있다.
본 발명에 따르면, 결제 모듈에 문제가 발생하여 결제 수단이 로드되지 않아도, 데이터베이스에 미리 저장된 결제 수단을 로드하여 결제를 진행할 수 있다.
발명의 효과는 이상에서 언급한 효과만으로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 청구범위 기재로부터 당해 기술 분야의 통상의 기술자에게 명확하게 이해될 수 있다.
도 1은 본 개시에 따른 전자 장치의 일 실시예를 나타낸다.
도 2는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 3은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다.
도 4는 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다.
도 5는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 6은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 7은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다.
도 8은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 9는 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다.
도 10은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다.
도 11은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 12는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 13은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
도 14 는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다.
본 개시에 기술된 실시예는 본 개시를 제한하는 것이 아니라 예시하는 것이고, 통상의 기술자는 첨부된 청구범위에 의해 정의된 본 개시의 범주를 벗어나지 않으면서, 다수의 대안적인 실시예를 설계할 수 있다. 실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 반대되는 기재가 존재하지 않는 한, 단수는 물론 복수를 모두 포함한다.
본 명세서 전체에서 어떤 부분이 어떤 구성요소들 또는 어떤 단계들을 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한, 어떤 부분이 구성요소들 또는 단계들을 반드시 모두 포함해야 하는 것은 아니고, 청구범위 또는 명세서 전체에 열거된 것 이외의 구성요소 또는 단계가 포함되는 것을 배제하는 것도 아니며, 단지 이들을 더 포함할 수 있음을 의미한다.
또한, 본 명세서에서 사용되는 제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 서수를 포함하는 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 문맥상 명세서의 일 부분에서 일 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리범위를 벗어나지 않으면서 제1 구성요소는 명세서의 다른 부분에서 제2 구성요소로 명명될 수 있고, 반대로 제2 구성요소도 명세서의 다른 부분에서 제1 구성요소로 명명될 수 있다.
본 명세서에서 "매커니즘", "요소", "수단", "구성"과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.
본 명세서(특히 청구범위에서)에서 "상기"의 용어 및 이와 유사한 지시 용어의 사용은 단수 및 복수 모두에 해당하는 것일 수 있다. 또한, 범위(range)를 기재한 경우 상기 범위에 속하는 개별적인 값을 포함하는 것으로서(이에 반하는 기재가 없다면), 상세한 설명에 상기 범위를 구성하는 각 개별적인 값을 기재한 것과 같다. 마지막으로, 방법을 구성하는 단계들에 대하여 명백하게 순서를 기재하거나 반하는 기재가 없다면, 상기 단계들은 적당한 순서로 재배열되어 행해질 수 있고, 반드시 상기 단계들의 기재 순서에 한정되는 것은 아니다. 모든 예들 또는 예시적인 용어(예들 들어, 등등)의 사용은 단순히 기술적 사상을 상세히 설명하기 위한 것으로서 청구범위에 의해 한정되지 않는 이상 상기 예들 또는 예시적인 용어로 인해 범위가 한정되는 것은 아니다. 통상의 기술자는 본 명세서에 개시된 실시예에 설계 조건 및 팩터에 따라 다양한 수정, 조합 및 변경을 부가하여 특허청구범위 또는 그 균등물의 범주에 속하는 새로운 실시예를 구성할 수 있다.
이하에서는 도면을 참조하여 본 개시의 실시예를 설명한다.
도 1 은 본 개시의 적어도 하나의 실시예를 실행하는데 사용될 수 있는 전자 장치(100)의 예시적이고 단순화된 블록도를 나타낸다. 다양한 실시예에서, 전자 장치(100)는 본 개시에서 서술된 임의의 시스템 또는 방법을 구현하는데 사용될 수 있다. 예를 들어, 전자 장치(100)는 데이터 서버, 웹 서버, 휴대용 컴퓨팅 디바이스, 개인용 컴퓨터, 태블릿 컴퓨터, 워크스테이션, 휴대폰, 스마트 폰(smart phone) 또는 아래에서 서술되는 임의의 다른 디바이스를 포함하는 임의의 전자 장치로서 사용되도록 구성될 수 있다.
전자 장치(100)는 메모리(120) 및 메모리(120)와 통신하도록 구성될 수 있는 하나 이상의 캐시 메모리 및 메모리 제어기를 갖는 하나 이상의 프로세서(110)를 포함할 수 있다. 추가적으로, 전자 장치(100)는 하나 이상의 포트(예컨대, USB(Universal Serial Bus), 헤드폰 잭, 라이트닝(Lightning) 커넥터, 썬더볼트(Thunderbolt) 커넥터 등)를 통해 전자 장치(100)에 연결될 수 있는 다른 디바이스를 포함할 수 있다. 전자 장치(100)에 연결될 수 있는 디바이스는 광섬유 커넥터를 수용하도록 구성되는 복수의 포트를 포함할 수 있다. 도시된 전자 장치(100)의 구성은 디바이스의 바람직한 실시예를 예시할 목적으로 특정 예시로서만 의도된다. 도시된 전자 장치(100)에는 본 실시예들과 관련된 구성요소들만이 도시되어 있다. 따라서, 전자 장치(100)에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음은 당해 기술분야의 통상의 기술자에게 자명하다.
프로세서(110)는 전자 장치(100)가 본 개시에서 서술된 임의의 실시예의 단계 또는 기능을 제공하도록 하기 위해 이용될 수 있다. 예를 들어, 프로세서(110)는 전자 장치(100) 내의 메모리(120)에 저장된 프로그램들을 실행함으로써, 전자 장치(100)를 전반적으로 제어한다. 프로세서(110)는 전자 장치(100) 내에 구비된 CPU(central processing unit), GPU(graphics processing unit), AP(application processor) 등으로 구현될 수 있으나, 이에 제한되지 않는다.
메모리(120)는 전자 장치(100) 내에서 처리되는 각종 데이터들을 저장하는 하드웨어로서, 메모리(120)는 전자 장치(100)에서 프로세서(110)를 통해 처리된 데이터들 및 처리될 데이터들을 저장할 수 있다. 또한, 메모리(120)는 본 개시의 적어도 하나의 실시예의 기능을 제공할 수 있는 기본 프로그래밍 및 데이터 구조를 저장하는 것은 물론, 본 개시의 실시예의 기능을 제공할 수 있는 애플리케이션들(프로그램, 코드 모듈, 명령어), 드라이버들 등을 저장할 수 있다. 메모리(120)는 DRAM(dynamic random access memory), SRAM(static random access memory) 등과 같은 RAM(random access memory), ROM(read-only memory), EEPROM(electrically erasable programmable read-only memory), CD-ROM, 블루레이 또는 다른 광학 디스크 스토리지, HDD(hard disk drive), SSD(solid state drive), 또는 플래시 메모리를 포함할 수 있다.
본 개시에 따른 방법 및 각 단계는 전자 장치(100) 또는 프로세서(110)가 수행할 수 있지만, 설명을 간단히 하기 위하여 아래부터는 프로세서(110)가 본 개시에 따른 방법 및 각 단계의 수행 주체임을 전제하여 설명한다.
도 2는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 일 실시예에서, 단계 S210에 따라, 프로세서(110)는 사용자로부터 결제 요청을 확인할 수 있다. 구체적으로, 프로세서(110)는 적어도 하나의 아이템에 대한 결제 요청을 확인할 수 있다. 결제 요청은 적어도 하나의 아이템에 관한 정보 및 결제 금액에 관한 정보를 포함할 수 있다.
일 실시예에서, 단계 S220에 따라, 프로세서(110)는 주문을 생성할 수 있다. 구체적으로, 프로세서(110)는 주문 식별 정보를 포함하는 주문에 대한 정보를 생성할 수 있다. 주문 식별 정보는 서로 다른 주문을 식별하기 위한 정보를 의미하며, 예를 들어, 각 주문 별 식별자 또는 주문 번호가 주문 식별 정보에 포함될 수 있다.
주문 또는 주문에 대한 정보는, 주문자에 대한 정보, 적어도 하나의 아이템에 대한 정보, 결제 정보, 배송 정보 중 하나 이상을 포함할 수 있다. 예를 들어, 주문 또는 주문에 대한 정보는, 주문자의 식별자, 주문자의 이름, 주문자의 주소, 아이템의 이름, 아이템의 가격, 아이템의 수량, 결제 타입, 결제 수단, 결제 금액, 배송 주소, 수취인, 배송비 및 배송요청사항 중 하나 이상을 포함할 수 있다.
일 실시예에서, 단계 S230에 따라, 프로세서(110)는 비동기 결제를 실행할지 여부를 확인할 수 있다. 구체적으로, 프로세서(110)는 주문에 대해 비동기 결제를 실행할지 여부를 확인할 수 있다. "비동기 결제"는 주문에 바로 이어서 결제가 진행되지 않고, 주문 이후 별도의 이벤트를 확인하거나 일정 시간이 지났을 때 결제가 진행되는 것을 의미할 수 있다. 이와 다르게 "동기 결제"는 주문에 바로 이어서 결제가 진행되는 것을 의미할 수 있다. 예를 들어, 결제 시스템의 장애로 인하여 주문에 대한 결제의 실패가 예상되거나 주문에 대한 동기 결제가 실패한 경우, 프로세서(110)는 주문에 바로 이어서 동기 결제를 실행하지 않고, 비동기 결제를 실행할 것을 확인할 수 있다.
일 실시예에서, 프로세서(110)는 서킷브레이커의 상태를 확인하고, 서킷브레이커의 상태를 기초로 주문에 대해 비동기 결제를 실행할지 여부를 확인할 수도 있다. 이러한 서킷브레이커 및 프로세서(110)의 동작에 대해서는 추후에 자세히 설명한다.
일 실시예에서, 프로세서(110)가 비동기 결제를 실행하지 않을 것으로 확인한 경우, 단계S240에 따라, 프로세서(110)는 동기 결제를 시도할 수 있다. 예를 들어, 프로세서(110)는 결제 모듈에 결제를 요청할 수 있다. 결제 모듈은 전자 장치(100)의 내부 또는 외부의 물리적인 장치일 수 있다. 이 경우, 전자 장치(100)는 결제 모듈과 통신할 수 있는 통신 수단을 구비할 수 있고, 프로세서(110)는 통신 수단을 이용하여 결제 모듈로 정보를 송신하거나, 결제 모듈로부터 정보를 수신할 수 있다. 또는 이와 다르게, 결제 모듈은 메모리(120)에 저장된 프로그램 또는 명령어 세트일 수도 있다. 이 경우, 프로세서(110)는 결제 모듈이 결제를 실행하도록 API(Application Programming Interface) 또는 함수를 호출할 수 있다.
일 실시예에서, 단계 S250에 따라, 프로세서(110)는 결제가 실패했는지 여부를 확인할 수 있다. 예를 들어 프로세서(110)는 결제 모듈로부터 결제 결과에 대한 정보를 확인할 수 있다. 결제 결과에 대한 정보는 결제의 성공 여부를 포함할 수 있다. 이 경우, 프로세서(110)는 결제 결과에 대한 정보를 확인하여 결제가 성공 또는 실패했는지 확인할 수 있다. 또한 결제 결과에 대한 정보는, 결제가 실패한 경우 결제가 실패한 원인에 관한 정보를 포함할 수 있다. 이 경우, 프로세서(110)는 결제 결과에 대한 정보를 확인하여 결제가 실패한 원인을 확인할 수 있고, 원인에 기초하여 서킷브레이커의 상태를 변경하거나, 다음 결제에 대해 비동기 결제를 실행할지 여부를 확인할 수 있다.
이와 다르게, 프로세서(110)는 결제 모듈로부터 결제의 실패 여부를 직접적으로 확인하지 못할 수 있다. 이 경우, 프로세서(110)는 결제 모듈이 기 설정된 시간 이내에 응답하지 않는다면 결제의 실패를 확인할 수 있다. 기 설정된 시간은 전자 장치(100) 또는 결제 모듈의 특성, 결제 상황 또는 주변 환경에 따라 정적 또는 동적으로 설정될 수 있다. 더 구체적으로, 프로세서(110)는 결제 모듈이 기 설정된 시간 이내에 응답하지 않는 횟수를 세고, 응답하지 않는 횟수가 기 설정된 임계 횟수 이상이라면 결제의 실패를 확인할 수도 있다. 이 경우, 기 설정된 임계 횟수는 전자 장치(100) 또는 결제 모듈의 특성, 결제 상황 또는 주변 환경에 따라 정적 또는 동적으로 설정될 수 있다.
일 실시예에서, 프로세서(110)는 결제 모듈로 결제 모듈의 상태에 대한 응답을 요청하고, 결제 모듈로부터 결제 모듈이 정상적이지 않다는 정보를 확인하면, 결제의 실패를 확인할 수도 있다.
일 실시예에서, 프로세서(110)가 결제의 실패를 확인하지 못했거나 결제의 성공을 확인한 경우, 단계 S261에 따라 프로세서(110)는 결제 성공 정보를 사용자에게 또는 다른 디바이스에 제공할 수 있다. 결제 성공 정보는 주문 식별 정보와 같은 주문에 대한 정보, 결제 금액, 결제 수단 및 아이템에 대한 정보 중 하나 이상을 포함할 수 있다.
프로세서(110)는 스크린 또는 화면 등의 입출력 디바이스에 표시되는 사용자 인터페이스에 결제가 성공하였다는 페이지, 메시지 혹은 아이콘을 표시하여 사용자에게 결제 성공 정보를 제공할 수 있다. 입출력 디바이스는 전자 장치(100)에 포함되거나, 전자 장치(100)에 포함되지 않을 수 있다.
일 실시예에서, 단계 S230의 결과로 프로세서(110)가 비동기 결제를 실행할 경우 또는 단계 S250의 결과로 프로세서(110)가 결제의 실패를 확인한 경우, 프로세서(110)는, 단계 S260에 따라, 주문의 결제 상태를 제1 상태로 설정할 수 있다. 예를 들어, 제1 상태는 "결제 시도 중" 상태에 대응되는 것일 수 있다.
또한, 단계 S230의 결과로 프로세서(110)가 비동기 결제를 실행할 것으로 확인한 경우 또는 단계 S250의 결과로 프로세서(110)가 결제의 실패를 확인한 경우, 프로세서(110)는 주문에 대한 결제를 시도 중이라는 정보를 사용자에게 또는 다른 디바이스에 제공할 수 있다.
일 실시예에서, 단계 S270에 따라, 프로세서(110)는 재고를 예약하고, 프로모션을 적용하고, 배송을 요청할 수 있다. 다시 말해, 프로세서(110)는 재고 예약, 프로모션 적용 및 배송 요청 중 적어도 하나를 수행할 수 있다.
프로세서(110)가 비동기 결제를 실행할 것으로 확인하고 실제로 아직 결제를 진행하지 않았더라도, 아이템을 배송하기 위하여 프로세서(110)는 아이템의 재고를 예약할 수 있다. 이는 결제가 비동기식으로 진행되더라도 아이템을 먼저 주문한 사용자에게 아이템을 제공할 수 있는 이점이 있다. 또한, 이는 결제가 비동기식으로 진행되더라도 배송이 미리 진행되므로 동기 결제에 비해 배송 시간이 지연되지 않는 이점이 있다.
프로세서(110)가 비동기 결제를 실행할 것으로 확인하고 실제로 아직 결제를 진행하지 않았더라도, 프로세서(110)는 프로모션을 적용할 수 있다. 이는 결제가 비동기식으로 진행되더라도 실제 결제가 이루어지기 전에 한정된 프로모션 예산에서 미리 프로모션 비용을 차감하므로, 프로모션 예산을 초과하여 프로모션이 적용되는 상황을 방지할 수 있는 이점이 있다.
프로세서(110)가 비동기 결제를 실행할 것으로 확인하고 실제로 아직 결제를 진행하지 않았더라도, 프로세서(110)는 아이템의 배송을 요청할 수 있다. 구체적으로, 프로세서(110)는 리테일 부서 또는 써드파티(3rd-party) 판매자에게 아이템의 배송 요청을 전송할 수 있다. 이는 결제가 비동기식으로 진행되더라도 아이템을 먼저 주문한 사용자에게 아이템을 제공할 수 있는 이점이 있다. 또한, 이는 결제가 비동기식으로 진행되더라도 배송이 미리 진행되므로 동기 결제에 비해 배송 시간이 지연되지 않는 이점이 있다.
일 실시예에서, 단계 S280에 따라, 프로세서(110)는, 주문의 결제에 관한 정보를 데이터베이스에 저장할 수 있다. 데이터베이스는 메모리(120) 의 물리적 또는 논리적 일부일 수 있고, 또는 전자 장치(100) 외부에 존재하는 디바이스일 수도 있다. 프로세서(110)가 이미 단계 S250의 결과로 비동기 결제를 실행할 것으로 확인하였으므로, 주문의 결제에 관한 정보는 추후 비동기 결제를 시도하기 위해 저장되는 정보일 수 있다. 구체적으로, 주문의 결제에 관한 정보는 주문 식별 정보, 결제 금액, 결제 수단에 관한 정보, 적어도 하나의 아이템에 관한 정보, 배송에 관한 정보 중 하나 이상을 포함할 수 있다. 예를 들어, 주문의 결제에 관한 정보는 결제 서비스 식별자, 결제 수단, 결제 금액, 결제 금액 통화 단위, 아이템 결제 금액, 아이템의 이름, 아이템의 카테고리 식별자, 아이템의 수량, 주문 번호, 주문서 번호, 주문 시간, 구매자의 식별자, 배송 주소, 수취인 이름, 수취인 전화번호, 결제 카드 식별자, 출금 계좌 식별자 및 할부 여부 중 하나 이상을 포함할 수 있다. 단, 주문의 결제에 관한 정보는 위에 한정되지 않고, 결제 또는 비동기 결제에 활용될 수 있는 어떤 정보도 주문의 결제에 관한 정보에 포함될 수 있다.
일 실시예에서, 프로세서(110)는, 결제 상태가 제1 상태로 설정된 것에 대응하여 주문의 결제에 관한 정보를 데이터베이스에 저장할 수 있다. 예를 들어, 결제 상태가 "결제 시도 중" 상태로 설정된 것에 대응하여, 프로세서(110)는 주문의 결제에 관한 정보를 비동기 결제에 관한 정보로서 데이터베이스에 저장할 수 있다.
도 3은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다. 일 실시예에서, 프로세서(110)는 비동기 결제를 실행할 것으로 확인한 경우, 구매 완료에 관한 정보를 사용자에게 제공할 수 있다. 이를 위하여 프로세서(110)는 입출력 디바이스에 표시되는 사용자 인터페이스에 구매 완료 페이지(300)를 표시하여 사용자에게 구매와 관련된 정보를 제공할 수 있다.
구매 완료 페이지(300)는 예상 배송 시간, 아이템의 이름, 수취인 이름, 수취인 주소, 수취인 연락처, 아이템 결제 금액, 배송비 및 결제 금액 중 하나 이상의 정보를 포함할 수 있다. 또한 일 실시예에서, 구매 완료 페이지(300)는 안내 영역(310)을 포함할 수 있다. 안내 영역(310)은 결제 오류 및 복구에 대한 안내는 물론, 결제 실패 시 주문이 취소될 수 있음을 알리는 안내를 포함할 수 있다. 안내 영역(310)은 결제 실패 시 별도의 안내가 제공될 수 있다는 안내를 포함할 수 있다.
도 4는 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다. 프로세서(110)는 비동기 결제를 실행할 것으로 확인한 경우, 주문에 관한 상세 정보를 사용자에게 제공할 수 있다. 이를 위하여 프로세서(110)는 입출력 디바이스에 표시되는 사용자 인터페이스에 주문 상세 페이지(400)를 표시하여 사용자에게 주문과 관련된 상세 정보를 제공할 수 있다.
주문 상세 페이지(400)는 주문일, 주문 식별 정보(주문번호), 아이템 결제 금액, 배송비, 결제 금액, 수취인 이름, 수취인 주소, 수취인 연락처, 예상 배송 시간, 아이템의 이름, 아이템의 수량 중 하나 이상의 정보를 포함할 수 있다.
일 실시예에서, 주문 상세 페이지(400)는 아이템 표시 영역(420)을 포함할 수 있다. 예를 들어, 서로 다른 아이템을 표시하기 위하여 주문 상세 페이지(400)는 하나 이상의 아이템 표시 영역(420)을 포함할 수 있고, 각 아이템 표시 영역(420)에는 서로 다른 아이템에 관한 정보가 각각 표시될 수 있다.
또한 일 실시예에서, 주문 상세 페이지(400)는 결제 상태 표시 영역(421)을 포함할 수 있고, 결제 상태 표시 영역에는 주문의 결제 상태가 표시될 수 있다. 이 때, 프로세서(110)가 비동기 결제를 실행할 것으로 확인한 경우, 결제 상태 표시 영역(421)에는 "결제 시도 중" 등의 정보(즉, 결제를 시도하고 있음을 나타내는 정보)가 표시될 수 있다. 즉, 도 2 에 나타난 단계 S230의 결과로 프로세서(110)가 비동기 결제를 실행할 것으로 확인한 경우 또는 단계 S250의 결과로 프로세서(110)가 결제의 실패를 확인한 경우, 프로세서(110)는 결제 상태 표시 영역(421)에 "결제 시도 중" 등의 정보를 표시하여 주문에 대한 결제를 시도 중이라는 정보를 사용자에게 또는 다른 디바이스에 제공할 수 있다. 이는 사용자가 비동기 결제가 진행 중임을 알 수 있도록 하는 이점이 있다.
"결제 시도 중" 등의 결제 시도 정보를 표시하는 것은 주문 상세 페이지(400)뿐만 아니라, 이와 유사한 사용자 인터페이스에도 적용될 수 있다. 예를 들어, 주문 목록 페이지와 같은 사용자 인터페이스에도 각 주문에 대해 결제 상태 표시 영역이 있을 수 있고, 프로세서(110)는 주문 목록 페이지의 각 주문 중 단계 S620에 따라 비동기 결제를 시도한 주문에 대응하는 결제 상태 표시 영역에 "결제 시도 중" 등의 결제 시도 정보를 표시할 수도 있다.
또한 일 실시예에서, 주문 상세 페이지(400)는 안내 영역(410)을 포함할 수 있다. 안내 영역(410)은 결제 오류 및 복구에 대한 안내는 물론, 결제 실패 시 주문이 취소될 수 있음을 알리는 안내를 포함할 수 있다. 안내 영역(410)은 결제 실패 시 별도의 안내가 제공될 수 있다는 안내를 포함할 수 있다.
도 5는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 일 실시예에서, 프로세서(110)는 서킷브레이커의 상태를 확인하고, 서킷브레이커의 상태를 기초로 주문에 대해 비동기 결제를 실행할지 여부를 확인할 수 있다. 이 과정의 보다 구체적인 사항이 도 5에 나타나 있다. 즉, 도 5에 나타난 단계들은, 도 2에 나타난 단계 S230의 구체적인 일 실시예를 나타내는 것일 수 있다. 하지만, 단계 S230의 실시예는 도 5에 나타난 단계들에만 한정되지는 않는다.
단계 S531에 따라, 프로세서(110)는 서킷브레이커의 상태를 확인할 수 있다. 서킷브레이커는 메모리(120)에 저장된 프로그램 또는 명령어 세트일 수 있다. 서킷브레이커는 열림(open) 상태 및 닫힘(closed) 상태 중 어느 하나의 상태를 가질 수 있다. 또 다른 실시예에서, 서킷브레이커는 열림 상태, 닫힘 상태 및 반-열림(half-open) 상태 중 어느 하나의 상태를 가질 수 있다. 도 5에는 열림 상태, 닫힘 상태 및 반-열림(half-open) 상태 중 어느 하나의 상태를 가질 수 있는 서킷브레이커의 상태에 따라 프로세서(110)가 행하는 동작이 순서도로 나타나 있다.
구체적으로, 단계 S532에 따라, 프로세서(110)는 서킷브레이커가 닫힘 상태에 있는지 확인할 수 있다. 서킷브레이커가 닫힘 상태에 있는 경우, 프로세서(110)는 단계 S533에 따라 동기 결제를 실행할 것으로 확인할 수 있다.
서킷브레이커가 닫힘 상태에 있지 않은 경우, 단계 S534에 따라, 프로세서(110)는 서킷브레이커가 반-열림 상태에 있는지 확인할 수 있다. 서킷브레이커가 반-열림 상태에 있는 경우, 프로세서(110)는 복수의 주문 중 하나 이상에 대해 비동기 결제를 실행할 것으로 확인하고, 복수의 주문 중 나머지 주문에 대해 동기 결제를 실행할 것으로 확인할 수 있다.
구체적으로, 프로세서(110)는 복수의 주문의 개수의 기 설정된 비율에 해당하는 개수의 주문에 대해 비동기 결제를 실행할 것으로 확인하고, 복수의 주문 중 나머지 주문에 대해 동기 결제를 실행할 것으로 확인할 수 있다. 예를 들어, 기 설정된 비율은 60%일 수 있고, 복수의 주문의 개수는 100개일 수 있다. 이 경우, 프로세서(110)는 100개 중 60%인 60개의 주문에 대해 비동기 결제를 실행할 것으로 확인하고, 100개의 주문 중 나머지 40개의 주문에 대해 동기 결제를 실행할 것으로 확인할 수 있다. 기 설정된 비율은 트래픽의 양, 결제 수단, 결제 금액, 결제 시간 또는 결제 실패율 등에 따라 정적 또는 동적으로 설정될 수 있다. 이는 복수의 주문 중 일부 주문에 대해서만 동기 결제를 실행하도록 함으로써 결제 모듈에 가해지는 트래픽의 양을 조절하고, 부하를 줄일 수 있는 이점이 있다.
또는 이와 다르게, 프로세서(110)는 복수의 주문의 개수의 기 설정된 비율에 해당하는 개수의 주문에 대해 동기 결제를 실행할 것으로 확인하고, 복수의 주문 중 나머지 주문에 대해 비동기 결제를 실행할 것으로도 확인할 수 있다. 이 경우 역시 기 설정된 비율은 트래픽의 양, 결제 수단, 결제 금액, 결제 시간 또는 결제 실패율 등에 따라 정적 또는 동적으로 설정될 수 있다.
또 다른 실시예에서, 프로세서(110)는 복수의 주문의 개수의 기 설정된 제1 비율에 해당하는 개수의 주문에 대해 비동기 결제를 실행할 것으로 확인하고, 복수의 주문의 개수의 기 설정된 제2 비율에 해당하는 개수의 주문에 대해 동기 결제를 실행할 것으로 확인할 수도 있다. 기 설정된 제1 비율 및 기 설정된 제2 비율은 트래픽의 양, 결제 수단, 결제 금액, 결제 시간 또는 결제 실패율 등에 따라 정적 또는 동적으로 설정될 수 있다.
일 실시예에서, 프로세서(110)는 단계 S534의 결과로 서킷브레이커가 반-열림 상태에 있지 않은 것을 확인한 경우, 서킷브레이커가 열림 상태에 있음을 확인하고, 단계 S536에 따라 비동기 결제를 실행할 것으로 확인할 수 있다.
도 5에 나타난 실시예에서는 프로세서(110)가 단계 S532에 따라 서킷브레이커가 닫힘 상태에 있는지 먼저 확인하고, 서킷브레이커가 닫힘 상태에 있지 않음이 확인된 경우, 단계 S534에 따라 서킷브레이커가 반-열림 상태에 있는지 확인하는 것으로 도시되어 있으나, 단계 S532 및 단계 S534의 순서는 역전될 수 있다. 즉, 프로세서(110)는 서킷브레이커가 반-열림 상태에 있는지 먼저 확인하고, 서킷브레이커가 반-열림 상태에 있지 않음이 확인된 경우, 서킷브레이커가 닫힘 상태에 있는지 확인할 수 있다.
또는 이와 달리, 프로세서(110)는 서킷브레이커가 열림 상태에 있는지 먼저 확인하고, 서킷브레이커가 열림 상태에 있지 않음이 확인된 경우, 서킷브레이커가 반-열림 상태에 있는지 확인할 수도 있다. 물론, 프로세서(110)는 서킷브레이커가 반-열림 상태에 있는지 먼저 확인하고, 서킷브레이커가 반-열림 상태에 있지 않음이 확인된 경우, 서킷브레이커가 열림 상태에 있는지 확인할 수도 있다.
또는 이와 달리, 프로세서(110)는 서킷브레이커가 닫힘 상태에 있는지 먼저 확인하고, 서킷브레이커가 닫힘 상태에 있지 않음이 확인된 경우, 서킷브레이커가 열림 상태에 있는지 확인할 수도 있다. 물론, 프로세서(110)는 서킷브레이커가 열림 상태에 있는지 먼저 확인하고, 서킷브레이커가 열림 상태에 있지 않음이 확인된 경우, 서킷브레이커가 닫힘 상태에 있는지 확인할 수도 있다.
서킷브레이커의 상태를 결정하기 위해 서킷브레이커의 상태를 하나씩 확인하는 순서는 트래픽의 양, 결제 수단, 결제 금액, 결제 시간 또는 결제 실패율 등에 따라 정적 또는 동적으로 설정될 수 있다. 예를 들어, 결제 실패율이 높은 경우, 서킷브레이커는 열림 상태에 있을 확률이 다른 두 상태에 있을 확률보다 높을 수 있다. 이 때 서킷브레이커가 열림 상태에 있는지 먼저 확인한다면, 한 번의 확인으로 서킷브레이커의 상태를 열림 상태로 확인할 수 있다. 반면, 서킷브레이커가 닫힘 상태에 있는지 먼저 확인한다면, 서킷브레이커의 상태가 닫힘 상태에 있지 않을 확률이 높으므로 서킷브레이커의 상태를 확인하기 위하여 서킷브레이커가 열림 상태(또는 반-열림 상태)에 있는지 추가로 확인해야할 수 있다. 따라서, 이 경우 두 번의 확인이 있어야 서킷브레이커의 상태를 열림 상태로 확인할 수 있게 된다. 따라서, 계산량을 줄이기 위해 일 실시예에서, 결제 실패율이 높은 경우, 프로세서(110)는 서킷브레이커가 열림 상태에 있는지 먼저 확인할 수 있다.
일 실시예에서, 서킷브레이커의 상태는 사용자에 의해 결정될 수 있다. 하지만, 보다 효율적인 서킷브레이커 활용을 위하여 일 실시예에서, 서킷브레이커의 상태는 주문에 대한 결제 실패율에 기초하여 결정될 수 있다. 결제 실패율은 동기 결제 시도의 실패율을 뜻하는 것일 수 있다. 예를 들어, 동기 결제를 100회 시도하였는데 그 중 30회의 결제가 실패하였다면, 결제 실패율은 30%가 될 수 있다. 프로세서(110)는 결제 실패율을 확인하고, 결제 실패율을 기초로 서킷브레이커의 상태를 결정할 수 있다. 이는 프로세서(110)가 결제 모듈의 상태를 직접 확인하지 않고도 결제 모듈로 가해지는 트래픽 또는 부하의 양을 조절하여 결제 모듈의 정상화를 유도할 수 있는 이점이 있다. 구체적으로, 프로세서(110)는 기 설정된 기간 동안의 주문에 대한 결제 실패율을 확인하고, 결제 실패율을 기초로 서킷브레이커의 상태를 결정할 수 있다.
일 실시예에서, 서킷브레이커는 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율 미만인 경우 반-열림 상태에서 닫힘 상태로 천이되고, 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율 이상인 경우 반-열림 상태에서 열림 상태로 천이될 수 있다. 기 설정된 기간 또는 기 설정된 결제 실패율은 트래픽의 양, 결제 수단, 결제 금액, 결제 시간 등에 따라 정적 또는 동적으로 설정될 수 있다. 예를 들어, 기 설정된 기간은 10초 내지 100초 사이의 값일 수 있다. 또한, 기 설정된 결제 실패율은 60% 또는 그 근처일 수 있다.
이와 달리, 서킷브레이커는 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율 이하인 경우 반-열림 상태에서 닫힘 상태로 천이되고, 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율 초과인 경우 반-열림 상태에서 열림 상태로 천이될 수도 있다.
또 다른 실시예에서, 서킷브레이커의 상태는 결제 성공률에 기초하여 결정될 수 있고, 기 설정된 기간 동안의 결제 성공률이 기 설정된 결제 성공률 미만인 경우 반-열림 상태에서 열림 상태로 천이되고, 기 설정된 기간 동안의 결제 성공률이 기 설정된 결제 성공률 이상인 경우 반-열림 상태에서 닫힘 상태로 천이될 수 있다. 또 다른 실시예에서, 기 설정된 기간 동안의 결제 성공률이 기 설정된 결제 성공률 이하인 경우 반-열림 상태에서 열림 상태로 천이되고, 기 설정된 기간 동안의 결제 성공률이 기 설정된 결제 성공률 초과인 경우 반-열림 상태에서 닫힘 상태로 천이될 수도 있다.
또 다른 실시예에서, 프로세서(110)는 기 설정된 개수의 결제 시도에 대해 결제 실패율을 확인하고, 결제 실패율을 기초로 서킷브레이커의 상태를 결정할 수 있다. 예를 들어, 200개의 결제 시도 중 70개가 실패한 경우, 프로세서(110)는 결제 실패율은 35%로 확인하고, 이를 기초로 서킷브레이커의 상태를 결정할 수 있다. 결제 시도는 동기 결제 시도, 비동기 결제 시도 또는 둘 다를 포함할 수 있다. 또한 결제 시도는 사용자의 결제 요청에 따른 실제 결제 시도와 상관없이, 결제 모듈의 상태를 확인하기 위하여 임의로 생성된 테스트 결제 시도를 포함할 수도 있다.
일 실시예에서, 프로세서(110)는 복수의 서킷브레이커의 상태를 확인하고, 복수의 서킷브레이커의 상태를 기초로 비동기 결제를 실행할지 여부를 확인할 수 있다. 복수의 서킷브레이커 각각은 서로 다른 작업, 프로세스, 단계, 알고리즘, 함수, 모듈 또는 API의 실패에 관한 것일 수 있다. 예를 들어 결제 창 API의 호출 실패율에 따라, 제1 서킷브레이커의 상태가 결정될 수 있고, 결제 사전 작업의 실패율에 따라 제2 서킷브레이커의 상태가 결정될 수 있다. 프로세서(110)는 제1 서킷브레이커 및 제2 서킷브레이커 모두가 닫힘 상태에 있는 경우 동기 결제를 실행하는 것으로 결정할 수 있다. 또는 프로세서(110)는 제1 서킷브레이커 또는 제2 서킷브레이커 중 하나가 열림 상태에 있는 경우 비동기 결제를 실행하는 것으로 결정할 수도 있다. 이와 같이 복수의 서킷브레이커를 사용하면 서로 다른 오류 이유 또는 서로 다른 모듈의 문제를 서로 분리하여 서킷브레이커의 상태를 관리할 수 있는 이점이 있다.
일 실시예에서, 서킷브레이커는 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율 초과인 경우 닫힘 상태에서 열림 상태로 천이될 수 있다. 예를 들어, 20초 동안의 결제 실패율이 60%를 초과하면 서킷브레이커는 닫힘 상태에서 열림 상태로 천이될 수 있다.
또한 일 실시예에서, 서킷브레이커는 열림 상태에서 기 설정된 시간이 도과되면 반-열림 상태로 천이될 수 있다. 예를 들어, 서킷브레이커가 열림 상태로 천이되고 20초가 지나면, 서킷브레이커는 열림 상태에서 반-열림 상태로 천이될 수 있다. 이와 같이 서킷브레이커를 열림 상태에서 바로 닫힘 상태로 천이시키는 것 대신 서킷브레이커를 열림 상태에서 반-열림 상태로 천이시키는 것은, 동기 결제의 실행 비율을 점진적으로 늘려서 결제 모듈에 적은 양의 트래픽 또는 부하만을 부과함과 동시에 결제 모듈이 정상화 되었는지 확인할 수 있게 되는 이점을 가진다.
도6은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 도 6 에 나타난 단계들은 도 2 에 나타난 단계들에 이어서 실행될 수 있으나, 본 개시는 이에 한정되지 않는다. 예를 들어, 서로 다른 복수의 주문에 대해 도 2 에 나타난 단계들이 복수 회 실행된 이후에 도 6 에 나타난 단계들이 실행될 수도 있다.
일 실시예에서, 프로세서(110)는 단계 S610에 따라, 데이터베이스로부터 하나 이상의 결제에 관한 정보를 확인할 수 있다. 결제에 관한 정보는 비동기 결제를 실행할 주문의 결제에 관한 정보를 포함할 수 있다. 구체적으로, 결제에 관한 정보는, 도 2의 단계 S270에 따라 데이터베이스에 저장된 주문의 결제에 관한 정보를 포함할 수 있다. 또한, 하나 이상의 결제에 관한 정보 각각은, 서로 다른 복수의 주문에 대해 도 2 에 나타난 단계들이 복수 회 실행되어, 복수 회 실행된 단계 S270에 따라 데이터베이스에 저장된 복수의 주문의 결제에 관한 정보 각각을 포함할 수 있다. 이와 같이 데이터베이스에 주문의 결제에 관한 정보가 저장되고, 저장된 결제에 관한 정보가 확인되기까지는 수 초, 수 분 내지 수십여 분이 걸릴 수 있다.
프로세서(110)는 단계 S620에 따라, 하나 이상의 결제에 관한 정보 각각에 대응되는 주문의 결제를 시도할 수 있다. 비동기 결제에 대응되는 주문의 결제 시도는 동기 결제 시도와 동일한 과정을 거치는 것을 의미할 수 있으나, 비동기 결제에 대응되는 주문의 결제 시도는 주문에 바로 이어서 진행되는 동기 결제 시도와 개념적으로 혹은 시간적으로 구분된다.
일 실시예에서, 프로세서(110)는 결제 실패율을 기초로 하나 이상의 결제에 관한 정보 각각에 대응되는 주문의 결제를 시도할 수도 있다. 예를 들어, 프로세서(110)는 결제 실패율이 기 설정된 값 이하인 경우, 하나 이상의 결제에 관한 정보 각각에 대응되는 주문의 결제를 시도할 수 있다. 이는 하나 이상의 결제에 관한 정보 각각에 대응되는 주문의 결제를 시도하더라도 결제에 실패할 확률을 낮출 수 있는 이점이 있다. 이 경우 결제 실패율은 동기 결제 시도, 비동기 결제 시도, 테스트 결제 시도 또는 이들의 조합의 실패율을 의미하는 것일 수 있다.
일 실시예에서, 단계 S630에 따라, 프로세서(110)는 결제의 성공 여부 또는 실패 여부를 확인할 수 있다. 결제가 실패하지 않았음을 프로세서(110)가 확인한 경우, 단계 S641에 따라, 프로세서(110)는 결제 상태를 제2 상태로 갱신할 수 있다. 다시 말해, 프로세서(110)는 주문의 결제가 실패한 경우 결제에 대응하는 주문의 결제 상태를 제2 상태로 갱신할 수 있다. 제2 상태는 "결제 성공"에 대응되는 것일 수 있다. 예를 들어, 도 2 에 나타난 단계 S230의 결과로 프로세서(110)가 비동기 결제를 실행할 것으로 확인하거나 단계 S250의 결과로 프로세서(110)가 결제의 실패를 확인하여, 프로세서(110)가 도 4 에 나타난 결제 상태 표시 영역(421)에 "결제 시도 중" 등의 정보를 표시한 경우, 단계 S641에 따라, 프로세서(110)는 결제 상태 표시 영역(421)에 "결제 성공" 또는 "결제 완료" 등의 정보를 표시할 수 있다. 또한 이 경우, 프로세서(110)는 주문 상세 페이지(400)로부터 안내 영역(410)를 제거할 수 있다. 실시 예에서 최초 비동기 결제를 수행할 경우, 해당 주문의 결제 상태는 제1 상태에 대응할 수 있고, 추후 결제가 성공할 경우, 상기 주문의 결제 상태는 제2 상태에 대응하고, 추후 결제가 실패할 경우, 상기 주문의 결제 상태를 제3 상태에 대응하는 것으로 설명될 수 있다.
"결제 성공" 또는 "결제 완료" 등의 결제 성공 정보를 표시하거나, 안내 영역을 제거하는 것은 주문 상세 페이지(400)뿐만 아니라, 이와 유사한 사용자 인터페이스에도 적용될 수 있다. 예를 들어, 주문 목록 페이지와 같은 사용자 인터페이스에도 각 주문에 대해 결제 상태 표시 영역이 있을 수 있고, 프로세서(110)는 주문 목록 페이지의 각 주문 중 단계 S620에 따라 비동기 결제를 시도한 주문에 대응하는 결제 상태 표시 영역에 "결제 성공" 또는 "결제 완료" 등의 결제 성공 정보를 표시할 수 있다.
단계 S630의 결과에 따라, 결제가 실패하였음을 프로세서(110)가 확인한 경우, 단계 S640에 따라, 프로세서(110)는 실패한 결제에 대응하는 주문의 결제 상태를 제3 상태로 갱신할 수 있다. 다시 말해, 프로세서(110)는 주문의 결제가 실패한 경우 결제에 대응하는 주문의 결제 상태를 제3 상태로 갱신할 수 있다. 제3 상태는 "결제 실패"에 대응되는 것일 수 있다.
예를 들어, 도 2 에 나타난 단계 S230의 결과로 프로세서(110)가 비동기 결제를 실행할 것으로 확인하거나 단계 S250의 결과로 프로세서(110)가 결제의 실패를 확인하여, 프로세서(110)가 도 4 에 나타난 결제 상태 표시 영역(421)에 "결제 시도 중" 등의 정보를 표시한 경우, 단계 S640에 따라, 프로세서(110)는 결제 상태 표시 영역(421)에 "결제 실패" 또는 "주문 취소" 등의 정보를 표시할 수 있다. 또한 이 경우, 프로세서(110)는 주문 상세 페이지(400)로부터 안내 영역(410)을 갱신하여 결제 실패에 대한 정보를 표시할 수 있다.
"결제 실패" 또는 "주문 취소" 등의 결제 실패 정보를 표시하거나, 안내 영역을 갱신하는 것은 주문 상세 페이지(400)뿐만 아니라, 이와 유사한 사용자 인터페이스에도 적용될 수 있다. 예를 들어, 주문 목록 페이지와 같은 사용자 인터페이스에도 각 주문에 대해 결제 상태 표시 영역이 있을 수 있고, 프로세서(110)는 주문 목록 페이지의 각 주문 중 단계 S620에 따라 비동기 결제를 시도한 주문에 대응하는 결제 상태 표시 영역에 "결제 실패" 또는 "주문 취소" 등의 결제 실패 정보를 표시할 수 있다.
일 실시예에서, 단계 S650에 따라, 프로세서(110)는 제3 상태에 대응하는 주문을 취소하고, 단계 S660에 따라, 제3 상태에 대응하는 주문의 배송 취소 요청을 전송할 수 있다. 즉, 프로세서(110)는, 결제 시도 중 주문의 결제가 실패한 경우, 실패한 결제에 대응하는 주문을 취소하고, 배송 취소 요청을 전송할 수 있다. 실패한 결제에 대응하는 주문은 도 2 의 단계 S220에서 생성된 주문을 포함할 수 있다. 또한, 배송 취소 요청은 도 2의 단계 S270에서 요청된 배송에 대응될 수 있다.
일 실시예에서, 프로세서(110)는 주문의 결제가 실패한 경우 결제의 실패 원인을 확인하고, 확인된 실패 원인을 기초로 실패한 결제에 대응하는 주문에 대한 재결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다. 예를 들어, 실패 원인이 계좌의 잔고 부족인 경우, 프로세서(110)는 사용자에게 계좌의 잔고가 부족하다는 정보를 제공하고, 사용자의 입금을 유도할 수 있다. 이후, 프로세서(110)는 주문에 대한 재결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다. 이는 사용자가 결제 실패에도 불구하고 아이템의 결제를 재시도하도록 유도할 수 있는 효과가 있다. 주문에 대한 재결제를 요청하기 위한 페이지는 체크아웃 페이지일 수 있다. 이와 같이 주문의 결제가 실패한 경우 체크아웃 페이지를 사용자에게 제공함으로써 다른 결제 수단으로 재결제를 요청할 수 있다.
일 실시예에서, 프로세서(110)는, 주문의 결제가 실패한 경우 결제에 대응하는 주문의 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하고, 결제 수단 변경에 대한 정보를 포함하는 페이지를 통해 결제 수단을 선택하는 사용자의 입력에 대응하여, 선택된 결제 수단을 사용하여 실패한 결제에 대응하는 주문의 결제를 시도할 수 있다. 예를 들어, 프로세서(110)는 계좌 이체 및 카드 결제 등의 결제 수단을 포함하는 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공할 수 있다. 결제 수단 변경에 대한 정보를 포함하는 페이지는 결제 수단 선택 페이지일 수 있다. 사용자는 카드 결제를 결제 수단으로 선택할 수 있고, 프로세서(110)는 카드 결제를 통해 실패한 결제에 대응하는 주문의 결제를 시도할 수 있다. 이 때, 프로세서(110)는 실패한 결제에 사용된 결제 수단의 선택을 제한할 수 있다. 예를 들어, 실패한 결제에 사용된 결제 수단이 계좌 이체인 경우, 프로세서(110)는 사용자가 결제 수단 선택 페이지에서 계좌 이체를 결제 수단으로 선택할 수 없도록, 해당 영역을 음영처리하거나, 표시하지 않을 수 있다. 이는 결제에 실패하더라도 사용자가 편리하게 결제를 재시도하도록 유도하는 이점이 있다.
도 7 은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다. 알림 페이지(700a, 700b)는 주문에 대한 주문 목록 표시 영역(710a, 710b) 및 결과 표시 영역(711a, 711b)를 포함할 수 있다. 결과 표시 영역(711a, 711b)은 주문 목록 표시 영역(710a, 710b)의 각 주문에 대한 주문 결과 또는 결제 결과를 표시할 수 있다.
일 실시예에서, 단계 S630의 결과에 따라, 결제에 관한 정보에 대응되는 주문의 결제가 실패하지 않았음을 프로세서(110)가 확인한 경우, 프로세서(110)는 "결제 성공" 또는 "결제 완료" 등의 결제 성공 정보를 알림 페이지(700a)의 결과 표시 영역(711a)에 표시할 수 있다. 또한 일 실시예에서, 단계 S630의 결과에 따라, 결제에 관한 정보에 대응되는 주문의 결제가 실패하였음을 프로세서(110)가 확인한 경우, 프로세서(110)는 "주문 취소" 또는 "결제 실패" 등의 결제 실패 정보를 알림 페이지(700b)의 결과 표시 영역(711b)에 표시할 수 있다. 이는 결제 창을 벗어난 사용자에게 비동기 결제의 상태가 갱신되었음을 알릴 수 있는 이점이 있다.
일 실시예에서, 단계 S630의 결과에 따라, 결제에 관한 정보에 대응되는 주문의 결제가 실패하였음을 프로세서(110)가 확인한 경우, 프로세서(110)는 주문 목록 표시 영역(710b)에서 실패한 결제에 대응하는 주문에 해당하는 영역에 장바구니 다시 담기 버튼(712b)을 표시할 수 있다. 이는 사용자가 보다 편리하게 주문에 포함된 아이템을 재결제할 수 있도록 하는 이점이 있다.
일 실시예에서, 단계 S630의 결과에 따라, 결제에 관한 정보에 대응되는 주문의 결제가 실패하였음을 프로세서(110)가 확인한 경우, 프로세서(110)는 사용자에게 적립금 또는 할인 쿠폰을 지급하고, 주문 목록 표시 영역(710b)에서 실패한 결제에 대응하는 주문에 해당하는 영역에 사용자에게 적립금 또는 할인 쿠폰을 지급하였다는 문구를 표시할 수 있다. 이는 사용자에게 주문에 포함된 아이템의 재결제를 유도할 수 있는 이점이 있다.
도 8은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 일 실시예에서, 단계 S810에 따라, 프로세서(110)는 결제 모듈로 결제 정보를 요청할 수 있다. 결제 정보는 결제 수단, 결제 은행, 최근 결제 수단, 카드 종류 및 계좌 정보와 같은 결제 또는 지불에 필요한 정보를 포함할 수 있다.
일 실시예에서, 단계 S820에 따라, 프로세서(110)는 결제 모듈로부터 결제 정보를 수신했는지 확인할 수 있다. 프로세서(110)는, 결제 모듈로부터 결제 정보를 수신한 경우, 단계 S831에 따라, 프로세서(110)는 수신된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하고, 결제 모듈로부터 결제 정보를 수신하지 못한 경우, 단계 S832에 따라, 프로세서(110)는 결제 정보 데이터베이스로부터 결제 정보를 확인하고, 단계 S832에 따라, 프로세서(110)는 확인된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다. 이는 결제 모듈이 정상적으로 동작하지 않아 프로세서(110)에게 결제 정보를 제대로 제공할 수 없더라도, 결제 정보 데이터베이스에 미리 백업된 결제 정보를 대신 사용하여 결제를 요청하기 위한 페이지를 사용자에게 제공하여 결제를 진행할 수 있는 이점이 있다. 결제를 요청하기 위한 페이지는 체크아웃 페이지일 수 있다.
체크아웃 페이지는 주문할 아이템의 이름 및 수량, 아이템의 결제 금액, 배송비, 결제 금액 및 결제 수단 등의 정보를 포함할 수 있다. 체크아웃 페이지는 결제하기 버튼 등 입력 인터페이스를 포함할 수 있고, 사용자가 결제하기 버튼 등 입력 인터페이스를 조작하는 것에 대응하여, 프로세서(110)는 주문할 아이템에 대한 결제 요청을 확인할 수 있다.
체크아웃 페이지는 결제 수단을 변경할 수 있는 버튼 등 입력 인터페이스를 포함할 수 있다. 사용자가 입력 인터페이스를 조작하는 것에 대응하여, 프로세서(110)는 결제 수단을 변경 또는 추가할 수 있는 결제 수단 선택 페이지를 생성할 수 있다. 구체적으로, 프로세서(110)는, 결제 모듈로부터 수신된 결제 정보 또는 결제 정보 데이터베이스로부터 확인된 결제 정보로부터 하나 이상의 결제 수단을 확인하고, 하나 이상의 결제 수단이 포함된 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공할 수 있다.
도 9는 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다. 구체적으로, 도 9는 결제 수단 선택 페이지(900)의 일 실시예를 도시한다.
결제 수단 선택 페이지(900)는 결제 수단의 목록을 포함할 수 있다. 목록에 포함되는 결제 수단은 결제 수단 표시 영역(920a, 920b, 920c, 920d, 920e)에 각각 표시될 수 있다.
일 실시예에서, 결제 모듈로부터 결제 정보를 수신하지 못한 경우, 체크아웃 페이지 또는 결제 수단 선택 페이지 는 사용할 수 없는 결제 수단에 대한 정보를 포함할 수 있다. 예를 들어, 도 9를 참조하면, 프로세서(110)는 결제 수단 선택 페이지(900)에서 사용할 수 없는 결제 수단에 대응하는 결제 수단 표시 영역(920c, 920d, 920e)을 회색 음영처리하여 표시할 수 있다. 이 경우, 프로세서는 결제 수단 표시 영역(920c, 920d, 920e)에 대응하는 결제 수단의 선택을 제한할 수 있다. 또한, 결제 수단 선택 페이지(900)는 일부 결제 수단의 사용이 불가능하다는 안내 문구를 포함하는 안내 영역(910)을 포함할 수 있다.
결제 수단 표시 영역(920a, 920b, 920c, 920d, 920e)은 결제 수단 선택 버튼(921)을 포함할 수 있다. 사용자는 결제 수단 선택 버튼(921)을 눌러 사용할 결제 수단을 선택할 수 있다.
결제 수단 표시 영역(920a, 920b, 920c, 920d, 920e)은 각 결제 수단에 따른 결제 세부 수단 표시 영역(922)을 포함할 수 있다. 예를 들어, 결제 수단 표시 영역(920a)에는 "계좌이체"의 결제 수단이 표시될 수 있다. 또한, 결제 세부 수단 표시 영역(922)에는 계좌이체가 가능한 은행 이름이 표시될 수 있다.
결제 수단 표시 영역(920a, 920b, 920c, 920d, 920e)은 선택 완료 버튼(924)을 포함할 수 있다. 사용자는 선택 완료 버튼(924)을 눌러 결제 수단 및 결제 세부 수단의 선택을 확정할 수 있다.
결제 수단 표시 영역(920a, 920b, 920c, 920d, 920e)은 결제 세부 수단 변경 버튼(923)을 포함할 수 있다. 사용자는 결제 세부 수단 변경 버튼(923)을 눌러 결제 세부 수단을 변경할 수 있다. 도10은 본 개시에 따른 결제 서비스 제공 방법에 관한 사용자 인터페이스의 실시예를 나타낸다. 구체적으로, 도 10은 결제 세부 수단 변경 페이지(1000)를 도시한다. 사용자가 결제 세부 수단 변경 버튼(923)을 눌렀을 때 결제 세부 수단 변경 페이지(1000)가 표시될 수 있다.
결제 세부 수단 변경 페이지(1000)는 결제 세부 수단의 목록을 포함할 수 있다. 목록에 포함되는 각 결제 세부 수단은 결제 세부 수단 표시 영역(1010a, 1010b, 1010c, 1010d, 1010e)에 각각 표시될 수 있다. 결제 세부 수단 표시 영역(1010a, 1010b, 1010c, 1010d, 1010e)은 결제 세부 수단 선택 버튼(1011)을 포함할 수 있다. 사용자는 결제 세부 수단 선택 버튼(1011)을 눌러 사용할 결제 세부 수단을 선택할 수 있다.
도11은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 일 실시예에서, 프로세서(110)는 1-클릭 구매 페이지를 생성(1110)할 수 있다. 1-클릭 구매 페이지는 별도의 결제 인증 절차 없이 주문을 결제할 수 있는 간소화된 체크아웃 페이지일 수 있다.
프로세서(110)는 결제 모듈(1113)로 결제 정보를 요청할 수 있다. 만약 프로세서(110)가 결제 모듈(1113)로부터 결제 정보를 수신하지 못한 경우(즉, 결제 정보 로드 실패 시), 일반 체크아웃 페이지를 제공(1111)할 수 있다. 체크아웃 페이지는 결제를 요청하기 위한 페이지일 수 있다.
프로세서(110)는 결제 정보 제공자(1112)로 결제 정보를 요청할 수 있다. 결제 정보 제공자(1112)는 메모리(120)에 저장된 프로그램 또는 명령어 세트일 수 있다. 결제 정보 제공자(1112)는 프로세서(110)로부터 결제 정보의 요청을 수신하고, 결제 모듈로 결제 정보를 요청할 수 있다. 만약 결제 정보 제공자(1112)가 결제 모듈(1113)로부터 결제 정보를 수신하지 못한 경우, 결제 정보 제공자(1112)는 결제 정보 데이터베이스(1114)로부터 결제 정보를 확인할 수 있다. 결제 정보 제공자(1112)는 결제 정보를 프로세서(110)에게 전달할 수 있다. 프로세서(110)는 결제 정보 제공자(1112)로부터 수신한 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다.
프로세서(110)는 사용자가 체크아웃 페이지를 통해 구매 버튼을 클릭(1120)한 경우, 주문을 생성(1121)할 수 있다. 주문은 주문 식별 정보를 포함할 수 있다.
서킷브레이커가 닫힌 경우, 프로세서(110)는 결제 사전 작업을 진행하고, 결제 창을 로드(1122)할 수 있다. 결제 사전 작업은 주문 정보(아이템, 결제 수단, 결제액 등)를 저장하고, 결제 창을 로드하기 위한 토큰을 확인하는 것을 포함할 수 있다. 로드된 결제 창을 통해 동기 결제가 실행될 수 있다.
생성된 주문의 결제가 실패하거나, 서킷브레이커가 열린 경우, 프로세서(110)는 비동기 결제를 요청(1123)할 수 있다. 비동기 결제를 요청(1123)하는 것은 비동기 결제를 실행할 것으로 확인하는 것을 포함할 수 있다. 프로세서(110)는 이어서 재고를 예약(1124)하고, 프로모션을 적용(1125)할 수 있다. 또한, 프로세서(110)는 비동기 결제 요청(1123)에 따라 결제 상태를 결제 시도 중으로 확인할 수 있다. 확인된 결제 상태에 관한 정보(결제 시도 중)는 입출력 디바이스를 통해 사용자에게 제공될 수 있다
프로세서(110)는 비동기 결제 요청(1123)에 따라, 비동기 결제 컨슈머(1126)에 주문의 결제에 관한 정보를 저장할 수 있다. 비동기 결제 컨슈머(1126)는 주문의 결제에 관한 정보를 저장할 수 있는 데이터베이스를 포함하거나, 데이터베이스에 포함될 수 있다. 주문은 결제에 실패한 주문 또는 서킷브레이커가 열려 있어서 동기 결제가 실행되지 않은 주문을 포함할 수 있다.
프로세서(110)는 비동기 결제 요청(1123)에 따라, 리테일 부서(1132)에 아이템의 배송(1133)을 요청하거나, 써드파티(3rd-party)판매자(1134)에게 아이템의 배송을 요청하거나, 여행 상품(1135)을 결제 완료 처리할 수 있다.
프로세서(110)는 비동기 결제 컨슈머(1126) 또는 데이터베이스로부터 하나 이상의 결제에 관한 정보를 확인하고, 비동기 결제를 처리(1127)할 수 있다. 다시 말해, 프로세서(110)는 비동기 결제 컨슈머(1126) 또는 데이터베이스로부터 하나 이상의 결제에 관한 정보를 확인하고, 결제에 관한 정보를 기초로 하나 이상의 결제에 관한 정보 각각에 대응되는 주문의 결제를 시도(결제 모듈에 결제를 요청(1128))하고, 주문의 결제의 성공 여부를 확인할 수 있다.
결제의 성공 여부에 기초하여, 프로세서(110)는 결제 결과를 갱신(1129)할 수 있다. 예를 들어, 결제가 성공한 경우, 프로세서(110)는 결제 상태를 제2 상태로 갱신할 수 있다. 또 다른 예를 들어, 결제가 실패한 경우, 프로세서(110)는 결제 상태를 제3 상태로 갱신할 수 있다. 갱신된 결제 상태에 관한 정보는 입출력 디바이스를 통해 사용자에게 제공될 수 있다.
결제가 실패한 경우, 프로세서(110)는 취소 또는 반품을 접수(1130)할 수 있다. 즉, 프로세서(110)는 실패한 결제에 대응하는 주문을 취소(1131)하고, 주문에 따라 배송이 이미 진행된 경우 반품 절차를 진행하는 것을 요청할 수 있다.
프로세서(110)는 리테일 부서(1132)에 의해 아이템의 배송(1133)이 준비 중이거나 배송(1133)이 이미 진행 중인 경우, 배송(1133)의 중지를 요청할 수 있다. 또한, 프로세서(110)는 써드파티 판매자(1134)에게 배송 요청 또는 주문의 취소 및 아이템의 반품을 요청할 수 있다. 또한, 프로세서(110)는 결제 완료된 여행 상품(1135)의 결제를 취소할 수 있다.
도12는 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 도 12 에 나타난 트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)는 A, B 또는 C 상태 중 어느 하나를 가질 수 있고(트래픽 제어기(1212)는 C 상태는 가질 수 없다), 프로세서(110)는 트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)의 상태에 따라(알맞은 화살표를 따라) 다음 절차를 진행할 수 있다.
트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)의 상태는 사용자, 프로세서(110) 또는 다른 디바이스에 의해 미리 설정되거나 변경될 수 있다.
또한, 본 개시에 따른 결제 서비스 제공 방법의 일 실시예는 트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)를 모두 포함하지 않을 수 있다. 이 경우, 트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)는 각각의 B 상태에 대응되는 화살표로 모두 대체될 수 있다. 즉, 트래픽 제어기(1212), 결제 수단 선택 페이지 트래픽 제어기(1215) 및 비동기 결제 트래픽 제어기(1218)로 들어가는 화살표는 각각의 B 상태에 대응되는 화살표에 바로 연결될 수 있다.
일 실시예에서, 프로세서(110)는 체크아웃 페이지를 제공(1210)하기 위하여 결제 정보 API를 호출(1211)할 수 있다. 프로세서(110)는 트래픽 제어기(1212)가 A 상태에 있는 경우, 결제 모듈로 결제를 요청(1213)하고, 트래픽 제어기(1212)가 B 상태에 있는 경우, 결제 정보를 로드(1214)할 수 있다. 프로세서(110)는 결제 정보를 로드(1214)하기 위해 결제 모듈에 결제 정보를 요청할 수 있다. 만약 결제 정보의 로드(1214)가 실패한 경우, 프로세서(110)는 단순화된 결제 수단 선택 페이지 데이터(1221)를 결제 정보로 사용할 수 있다. 예를 들어, 프로세서(110)는 데이터베이스로부터 최근 결제 수단 등의 결제 정보를 확인할 수 있다.
일 실시예에서, 결제 수단 트래픽 제어기(1215)가 C 상태에 있는 경우, 프로세서(110)는 단순화된 결제 수단 선택 페이지를 활성화(1222)할 수 있다. 단순화된 결제 수단 선택 페이지 는 사용할 수 없는 결제 수단을 사용자가 선택하는 것을 제한하는 사용자 인터페이스를 포함하거나, 사용할 수 없는 결제 수단에 대응하는 사용자 인터페이스를 제거한 페이지일 수 있다.
일 실시예에서, 결제 수단 트래픽 제어기(1215)가 B 상태에 있는 경우, 프로세서(110)는 결제 수단 선택 페이지 서킷브레이커의 상태(1216)를 확인할 수 있다. 결제 수단 선택 페이지 서킷브레이커의 상태(1216)가 열림 상태에 있는 경우, 프로세서(110)는 단순화된 결제 수단 선택 페이지를 활성화(1222)할 수 있다. 또한, 결제 수단 선택 페이지 서킷브레이커의 상태(1216)가 열림 상태에 있지 않거나 결제 수단 선택 페이지 트래픽 제어기(1215)의 상태가 A 상태에 있는 경우, 프로세서(110)는 주문이 적용 대상인지 확인(1217)할 수 있다. 여기서 적용 대상은 비동기 결제가 실행될 수 있는 주문을 의미할 수 있다.
여기서 적용 대상은 원터치 결제(결제하기 버튼 터치 시 별도의 인증절차 없이 바로 결제가 진행되는 결제)를 활성화한 사용자의 주문, 결제 수단이 본 개시에 따른 서비스 제공자의 자체 결제 서비스 또는 자체 금융 서비스인 주문, 결제 금액이 기 설정된 금액 이하인 주문 등이 포함할 수 있다. 또한, 기프트 카드(gift-card)의 주문, 전자적 선물(E-gift) 주문, 구독 주문, 여행 상품 주문 등의 주문은 적용 대상에 포함되지 않을 수 있다. 또한, 서비스 제공자의 서비스에 적립된 적립금을 사용하는 주문은 적용 대상에 포함되지 않을 수 있다.
일 실시예에서, 주문이 적용 대상인 경우, 프로세서(110)는 비동기 결제 트래픽 제어기(1218)의 상태를 확인할 수 있다. 비동기 결제 트래픽 제어기(1218)의 상태가 B 상태인 경우, 프로세서(110)는 비동기 결제 서킷브레이커의 상태(1219)를 확인할 수 있다.
일 실시예에서, 비동기 결제 트래픽 제어기(1218)의 상태가 C 상태이거나, 비동기 결제 서킷브레이커의 상태(1219)가 열림 상태에 있는 경우, 프로세서(110)는 적립금의 사용을 비활성화할 수 있다.
일 실시예에서, 주문이 적용 대상이 아니거나, 비동기 결제 트래픽 제어기(1218)의 상태가 A 상태이거나, 비동기 결제 서킷브레이커의 상태(1219)가 열림 상태에 있지 않은 경우, 프로세서(110)는 블록(1220)에 따라 단순화된 결제 수단 선택 페이지 데이터(1221)를 사용하여, 단순화된 결제 수단 선택 페이지를 활성화(1222)하고, 적립금의 사용을 비활성화(1223)할 수 있다.
도13은 본 개시에 따른 결제 서비스 제공 방법의 일 실시예에 관한 흐름도를 나타낸다. 도 13 에 나타난 트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)는 A, B 또는 C 상태 중 어느 하나를 가질 수 있고(트래픽 제어기(1312)는 C 상태는 가질 수 없다), 프로세서(110)는 트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)의 상태에 따라(알맞은 화살표를 따라) 다음 절차를 진행할 수 있다.
트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)의 상태는 사용자, 프로세서(110) 또는 다른 디바이스에 의해 미리 설정되거나 변경될 수 있다.
또한, 본 개시에 따른 결제 서비스 제공 방법의 일 실시예는 트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)를 모두 포함하지 않을 수 있다. 이 경우, 트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)는 모두 각각의 B 상태에 대응되는 화살표로 대체될 수 있다. 즉, 트래픽 제어기(1312) 및 비동기 결제 트래픽 제어기(1317)로 들어가는 화살표는 각각의 B 상태에 대응되는 화살표에 바로 연결될 수 있다.
일 실시예에서, 프로세서(110)는 사용자의 결제 버튼 클릭(1310)에 대응하여 주문을 생성(1311)할 수 있다. 트래픽 제어기(1312)의 상태가 B 상태인 경우, 프로세서(110)는 생성된 주문이 적용 대상인지 확인(1316)할 수 있다. 여기서 적용 대상은 도 12 에 관한 상술한 설명에서 언급한 적용 대상과 동일한 개념을 의미할 수 있다.
일 실시예에서, 프로세서(11)는 주문이 적용 대상인 경우, 비동기 결제 트래픽 제어기(1317)의 상태를 확인할 수 있다. 비동기 결제 트래픽 제어기(1317)의 상태가 B 상태인 경우, 프로세서(110)는 결제 창 서킷브레이커의 상태(1318)를 확인할 수 있다. 결제 창 서킷브레이커의 상태(1318)는 결제 창 로드의 실패율에 따라 결정될 수 있다.
결제 창 서킷브레이커의 상태(1318)가 닫힘 상태 또는 반-열림 상태에 있는 경우, 프로세서(110)는 결제 사전 작업 서킷브레이커의 상태(1319)를 확인할 수 있다. 결제 사전 작업 서킷브레이커의 상태(1319)는 결제 사전 작업의 실패율에 따라 결정될 수 있다.
일 실시예에서, 트래픽 제어기(1312)의 상태가 A 상태이거나, 생성된 주문이 적용 대상이 아니거나, 비동기 결제 트래픽 제어기(1317)의 상태가 A 상태이거나, 결제 사전 작업 서킷브레이커의 상태(1319)가 닫힘 상태 또는 반-열림 상태에 있는 경우, 프로세서(110)는 결제 사전 작업을 호출하고 성공 여부를 확인(1313)할 수 있다. 결제 사전 작업은 주문 정보(아이템, 결제 수단, 결제액 등)를 저장하고, 결제 창을 로드하기 위한 토큰을 확인하는 것을 포함할 수 있다.
일 실시예에서, 결제 사전 작업 호출이 성공한 경우, 프로세서(110)는 결제 창을 열 수 있다(1314). 결제 창은 입출력 디바이스의 사용자 인터페이스에 표시되어, 결제 창을 통해 사용자의 입력에 대응하여 결제를 진행할 수 있다.
일 실시예에서, 결제 사전 작업 호출이 실패한 경우, 프로세서(110)는 주문의 실패를 확인(1315)할 수 있다.
일 실시예에서, 비동기 결제 트래픽 제어기(1317)의 상태가 C 상태이거나, 결제 창 서킷브레이커의 상태(1318)가 열림 상태에 있거나, 결제 사전 작업 서킷브레이커 상태(1319)가 열림 상태에 있는 경우, 프로세서(110)는 적립금의 사용 여부를 확인(1320)할 수 있다. 적립금이 사용되는 경우, 프로세서(110)는 주문의 실패를 확인(1322)할 수 있다. 적립금이 사용되지 않는 경우, 프로세서(110)는 비동기 결제를 진행(1321)할 수 있다. 즉, 프로세서(110)는 생성된 주문에 대해 비동기 결제를 실행할 것을 확인할 수 있다.
도 14 는 일 실시예에 따른 전자 장치(100)의 동작 방법을 나타낸다. 도 14 의 동작 방법의 각 단계는 도 1의 전자 장치(100)에 의해 수행될 수 있으므로, 도 1 과 중복되는 내용에 대해서는 설명을 생략한다.
단계 S1410에서, 전자 장치(100)는, 적어도 하나의 아이템에 대한 결제 요청을 확인할 수 있다.
전자 장치(100)는, 결제 모듈로 결제 정보를 요청하고, 요청 결과 결제 모듈로부터 결제 정보를 수신한 경우, 수신된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하고, 요청 결과 결제 모듈로부터 결제 정보를 수신하지 못한 경우, 결제 정보 데이터베이스로부터 결제 정보를 확인하고, 확인된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다.
전자 장치(100)는, 수신된 결제 정보 또는 확인된 결제 정보로부터 하나 이상의 결제 수단을 확인하고, 하나 이상의 결제 수단이 포함된 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공할 수 있다.
단계 S1420에서, 전자 장치(100)는, 확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인할 수 있다.
서킷브레이커의 상태는 주문에 대한 결제 실패율에 기초하여 결정될 수 있다.
서킷브레이커는 열림(open) 상태, 닫힘(closed) 상태 및 반-열림(half-open) 상태 중 어느 하나의 상태를 가질 수 있다.
전자 장치(100)는, 서킷브레이커가 반-열림 상태에 있는 경우, 복수의 주문 중 하나 이상에 대해 비동기 결제를 실행할 것으로 확인하고, 복수의 주문 중 나머지 주문에 대해 동기 결제를 실행할 것으로 확인할 수 있다.
서킷브레이커는, 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율보다 낮은 경우 반-열림 상태에서 닫힘 상태로 천이되고, 기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율보다 높은 경우 반-열림 상태에서 열림 상태로 천이될 수 있다.
단계 S1430에서, 전자 장치(100)는, 확인된 서킷브레이커의 상태에 기초하여 결제 요청에 대한 비동기 결제를 실행할 경우, 주문의 결제 상태를 제1 상태로 설정할 수 있다.
전자 장치(100)는, 주문의 결제 상태가 제1 상태로 설정된 경우, 주문에 대응하는 적어도 하나의 아이템에 대한 배송 요청을 전송할 수 있다.
전자 장치(100)는, 주문의 결제 상태가 제1 상태로 설정된 경우, 아이템에 대한 재고를 예약할 수 있다.
전자 장치(100)는, 주문의 결제 상태가 제1 상태로 설정된 경우, 아이템이 프로모션 대상인 경우, 프로모션을 적용할 수 있다.
단계 S1440에서, 전자 장치(100)는, 결제 상태가 제1 상태로 설정된 것에 대응하여 주문의 결제에 관한 정보를 데이터베이스에 저장할 수 있다.
주문의 결제에 관한 정보는, 주문 식별 정보, 결제 금액, 결제 수단에 관한 정보, 적어도 하나의 아이템에 관한 정보, 배송에 관한 정보 중 하나 이상을 포함할 수 있다.
단계 S1450에서, 전자 장치(100)는, 데이터베이스로부터 결제에 관한 정보를 확인하고, 결제에 관한 정보를 기초로 결제에 관한 정보에 대응되는 주문의 결제를 시도할 수 있다.
단계 S1460에서, 전자 장치(100)는, 주문의 결제의 성공 여부를 확인할 수 있다.
단계 S1470에서, 전자 장치(100)는, 주문의 결제에 성공한 경우, 주문의 결제 상태를 제2 상태로 갱신할 수 있다.
전자 장치(100)는, 주문의 결제가 실패한 경우, 주문의 결제 상태를 제3 상태로 갱신하고, 제3 상태에 대응하는 주문의 배송 취소 요청을 전송할 수 있다.
전자 장치(100)는, 주문의 결제가 실패한 경우, 결제의 실패 원인을 확인하고, 확인된 실패 원인을 기초로 실패한 결제에 대응하는 주문에 대한 재결제를 요청하기 위한 페이지를 사용자에게 제공할 수 있다.
전자 장치(100)는, 주문의 결제가 실패한 경우, 주문에 대한 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하고, 결제 수단 변경에 대한 정보를 포함하는 페이지를 통해 결제 수단을 선택하는 사용자의 입력에 대응하여, 선택된 결제 수단을 사용하여 실패한 결제에 대응하는 주문의 결제를 시도할 수 있다.
이상 설명된 본 개시에 따른 실시예들은 다양한 컴퓨터 구성요소를 통하여 수행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능한 기록 매체 또는 비일시적 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치 또는 전자 장치는 본 개시에 따른 처리를 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어, 소프트웨어, 또는 이들의 조합들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 데이터 처리 또는 이들의 조합 등을 위하여 종래 기술을 채용할 수 있다.

Claims (15)

  1. 전자 장치의 결제 서비스 제공 방법에 있어서,
    적어도 하나의 아이템에 대한 결제 요청을 확인하는 단계;
    확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하는 단계;
    상기 확인된 서킷브레이커의 상태에 기초하여 상기 결제 요청에 대한 비동기 결제를 실행할 경우, 상기 주문의 결제 상태를 제1 상태로 설정하는 단계;
    상기 결제 상태가 제1 상태로 설정된 것에 대응하여 상기 주문의 결제에 관한 정보를 데이터베이스에 저장하는 단계;
    상기 데이터베이스로부터 결제에 관한 정보를 확인하고, 상기 결제에 관한 정보를 기초로 상기 결제에 관한 정보에 대응되는 주문의 결제를 시도하는 단계;
    상기 주문의 결제의 성공 여부를 확인하는 단계; 및
    상기 주문의 결제에 성공한 경우, 상기 주문의 결제 상태를 제2 상태로 갱신하는 단계를 포함하는, 결제 서비스 제공 방법.
  2. 제1항에 있어서,
    상기 주문의 결제 상태가 제1 상태로 설정된 경우, 상기 주문에 대응하는 상기 적어도 하나의 아이템에 대한 배송 요청을 전송하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  3. 제2항에 있어서,
    상기 주문의 결제가 실패한 경우, 상기 주문의 결제 상태를 제3 상태로 갱신하는 단계; 및
    상기 제3 상태에 대응하는 주문의 배송 취소 요청을 전송하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  4. 제1항에 있어서,
    상기 주문의 결제가 실패한 경우, 상기 결제의 실패 원인을 확인하고, 확인된 실패 원인을 기초로 상기 실패한 결제에 대응하는 주문에 대한 재결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  5. 제1항에 있어서,
    상기 주문의 결제가 실패한 경우, 상기 주문에 대한 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하는 단계; 및
    상기 결제 수단 변경에 대한 정보를 포함하는 페이지를 통해 결제 수단을 선택하는 상기 사용자의 입력에 대응하여, 선택된 결제 수단을 사용하여 상기 실패한 결제에 대응하는 주문의 결제를 시도하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  6. 제1항에 있어서,
    상기 서킷브레이커의 상태는 주문에 대한 결제 실패율에 기초하여 결정되는, 결제 서비스 제공 방법.
  7. 제1항에 있어서,
    상기 서킷브레이커는 열림(open) 상태, 닫힘(closed) 상태 및 반-열림(half-open) 상태 중 어느 하나의 상태를 가지고,
    상기 서킷브레이커의 상태를 확인하는 단계는,
    상기 서킷브레이커가 반-열림 상태에 있는 경우, 복수의 상기 주문 중 하나 이상에 대해 비동기 결제를 실행할 것으로 확인하고, 상기 복수의 상기 주문 중 나머지 주문에 대해 동기 결제를 실행할 것으로 확인하는 단계를 포함하는, 상기 결제 서비스 제공 방법.
  8. 제7항에 있어서,
    상기 서킷브레이커는,
    기 설정된 기간 동안의 주문에 대한 결제 실패율이 기 설정된 결제 실패율보다 낮은 경우 반-열림 상태에서 닫힘 상태로 천이되고, 상기 기 설정된 기간 동안의 주문에 대한 결제 실패율이 상기 기 설정된 결제 실패율보다 높은 경우 반-열림 상태에서 열림 상태로 천이되는, 결제 서비스 제공 방법.
  9. 제1항에 있어서,
    상기 주문의 결제 상태가 제1 상태로 설정된 경우, 상기 아이템에 대한 재고를 예약하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  10. 제1항에 있어서,
    상기 주문의 결제 상태가 제1 상태로 설정된 경우, 상기 아이템이 프로모션 대상인 경우, 프로모션을 적용하는 단계를 더 포함하는, 결제 서비스 제공 방법.
  11. 제1항에 있어서,
    상기 결제 요청을 확인하는 단계는,
    결제 모듈로 결제 정보를 요청하는 단계; 및
    상기 요청 결과 상기 결제 모듈로부터 결제 정보를 수신한 경우, 수신된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하고, 상기 요청 결과 상기 결제 모듈로부터 결제 정보를 수신하지 못한 경우, 결제 정보 데이터베이스로부터 결제 정보를 확인하고, 확인된 결제 정보를 기초로 결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계를 포함하는, 결제 서비스 제공 방법.
  12. 제11항에 있어서,
    상기 결제를 요청하기 위한 페이지를 사용자에게 제공하는 단계는,
    상기 수신된 결제 정보 또는 상기 확인된 결제 정보로부터 하나 이상의 결제 수단을 확인하는 단계; 및
    상기 하나 이상의 결제 수단이 포함된 결제 수단 변경에 대한 정보를 포함하는 페이지를 사용자에게 제공하는 단계를 포함하는, 결제 서비스 제공 방법.
  13. 제1항에 있어서,
    상기 주문의 결제에 관한 정보는,
    상기 주문 식별 정보, 결제 금액, 결제 수단에 관한 정보, 상기 적어도 하나의 아이템에 관한 정보, 배송에 관한 정보 중 하나 이상을 포함하는, 결제 서비스 제공 방법.
  14. 전자 장치로서,
    적어도 하나의 프로그램이 저장된 메모리; 및
    상기 적어도 하나의 프로그램을 실행함으로써,
    적어도 하나의 아이템에 대한 결제 요청을 확인하고,
    확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하고,
    상기 확인된 서킷브레이커의 상태에 기초하여 상기 결제 요청에 대한 비동기 결제를 실행할 경우, 상기 주문의 결제 상태를 제1 상태로 설정하고,
    상기 결제 상태가 제1 상태로 설정된 것에 대응하여 상기 주문의 결제에 관한 정보를 데이터베이스에 저장하고,
    상기 데이터베이스로부터 결제에 관한 정보를 확인하고, 상기 결제에 관한 정보를 기초로 상기 결제에 관한 정보에 대응되는 주문의 결제를 시도하고,
    상기 주문의 결제의 성공 여부를 확인하고,
    상기 주문의 결제에 성공한 경우, 상기 주문의 결제 상태를 제2 상태로 갱신하는 프로세서를 포함하는, 전자 장치.
  15. 전자 장치의 결제 서비스 제공 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적 기록매체로서,
    상기 결제 서비스 제공 방법은,
    적어도 하나의 아이템에 대한 결제 요청을 확인하는 단계;
    확인된 결제 요청에 대응하여 주문 식별 정보를 포함하는 주문에 대한 정보를 생성하고, 서킷브레이커의 상태(state)를 확인하는 단계;
    상기 확인된 서킷브레이커의 상태에 기초하여 상기 결제 요청에 대한 비동기 결제를 실행할 경우, 상기 주문의 결제 상태를 제1 상태로 설정하는 단계;
    상기 결제 상태가 제1 상태로 설정된 것에 대응하여 상기 주문의 결제에 관한 정보를 데이터베이스에 저장하는 단계;
    상기 데이터베이스로부터 결제에 관한 정보를 확인하고, 상기 결제에 관한 정보를 기초로 상기 결제에 관한 정보에 대응되는 주문의 결제를 시도하는 단계;
    상기 주문의 결제의 성공 여부를 확인하는 단계; 및
    상기 주문의 결제에 성공한 경우, 상기 주문의 결제 상태를 제2 상태로 갱신하는 단계를 포함하는, 비일시적 기록 매체.
PCT/KR2022/006692 2022-04-29 2022-05-10 결제 서비스 제공 방법 및 그 장치 WO2023210852A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220053439A KR20230153713A (ko) 2022-04-29 2022-04-29 결제 서비스 제공 방법 및 그 장치
KR10-2022-0053439 2022-04-29

Publications (1)

Publication Number Publication Date
WO2023210852A1 true WO2023210852A1 (ko) 2023-11-02

Family

ID=88518989

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/006692 WO2023210852A1 (ko) 2022-04-29 2022-05-10 결제 서비스 제공 방법 및 그 장치

Country Status (3)

Country Link
KR (1) KR20230153713A (ko)
TW (1) TW202343334A (ko)
WO (1) WO2023210852A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060016570A (ko) * 2004-08-18 2006-02-22 권도균 가승인용 신용카드 단말기 및 이를 이용한 신용카드 결제시스템 및 결제 방법
KR20140065930A (ko) * 2012-11-22 2014-05-30 주식회사 한국스마트카드 유통지불오류 처리방법
KR20170037950A (ko) * 2014-07-31 2017-04-05 알리바바 그룹 홀딩 리미티드 네트워크 지불을 제어하는 방법 및 장치
CN107133797A (zh) * 2017-04-28 2017-09-05 努比亚技术有限公司 一种支付异常自动检测方法、终端及计算机可读存储介质
KR20200134560A (ko) * 2019-05-22 2020-12-02 카페24 주식회사 이상치 발생 여부 검출 방법, 컴퓨팅 디바이스 및 컴퓨터 판독 가능한 저장 매체
KR20220030762A (ko) * 2020-09-03 2022-03-11 주식회사 오윈 결제 정보 유실 방지 방법 및 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060016570A (ko) * 2004-08-18 2006-02-22 권도균 가승인용 신용카드 단말기 및 이를 이용한 신용카드 결제시스템 및 결제 방법
KR20140065930A (ko) * 2012-11-22 2014-05-30 주식회사 한국스마트카드 유통지불오류 처리방법
KR20170037950A (ko) * 2014-07-31 2017-04-05 알리바바 그룹 홀딩 리미티드 네트워크 지불을 제어하는 방법 및 장치
CN107133797A (zh) * 2017-04-28 2017-09-05 努比亚技术有限公司 一种支付异常自动检测方法、终端及计算机可读存储介质
KR20200134560A (ko) * 2019-05-22 2020-12-02 카페24 주식회사 이상치 발생 여부 검출 방법, 컴퓨팅 디바이스 및 컴퓨터 판독 가능한 저장 매체
KR20220030762A (ko) * 2020-09-03 2022-03-11 주식회사 오윈 결제 정보 유실 방지 방법 및 장치

Also Published As

Publication number Publication date
KR20230153713A (ko) 2023-11-07
TW202343334A (zh) 2023-11-01

Similar Documents

Publication Publication Date Title
US7975020B1 (en) Dynamic updating of rendered web pages with supplemental content
US8296392B2 (en) Browser-based retrieval and display of content associated with a link that matches a link signature
WO2010030116A2 (ko) 검색 광고에 대한 경매 및 과금을 수행하기 위한 방법, 시스템 및 컴퓨터 판독 가능한 기록 매체
WO2019019245A1 (zh) 基金组合购买方法、系统及存储介质
WO2019212295A1 (ko) 공급자와 판매자간 전자 상거래 중계 시스템 및 중계 방법
WO2018056689A1 (ko) 오픈 마켓에서의 전자상거래에 있어서 결제 후 랜덤 추가 할인을 제공하는 방법, 장치 및 시스템
WO2021025387A1 (ko) 통합 주문 및 통합 배송이 가능한 전자상거래 방법 및 이를 위한 서버
CN101910995B (zh) 信息处理设备和程序
WO2014107067A1 (ko) 이동통신단말기를 이용한 셀프 카드 결제 시스템 및 방법
WO2015122601A1 (ko) 단말과 서비스 제공 장치와 쿠폰 서버, 그를 포함하는 전자 지갑 시스템, 그 제어 방법 및 컴퓨터 프로그램이 기록된 기록매체
WO2017111195A1 (ko) 신뢰도 평가기반의 차량 직거래 인터페이스 제공 방법 및 이를 운용하는 서버
WO2016190503A1 (ko) 대리결제장치 및 그 동작 방법
WO2017078378A2 (ko) 전자상거래에서의 물품 배송 요금 산출 시스템
WO2023210852A1 (ko) 결제 서비스 제공 방법 및 그 장치
WO2013191427A1 (ko) 담보거래 서비스 방법
WO2017135609A1 (ko) 판매 이익금 분배 시스템 및 방법
WO2017135608A1 (ko) 이벤트 성공에 따른 판매 수익 분배를 이용한 상품 판매 촉진 시스템 및 방법
WO2022186404A1 (ko) 아이템 판매 정보 처리를 위한 전자 장치 및 그 방법
CN111275450A (zh) 一种商品退货后的关联优惠信息的处理方法和系统
WO2020222558A2 (ko) 정산 서버 및 그 방법
WO1991014223A1 (en) Programming system and method, and programming device and terminals constituting the system
WO2018056691A1 (ko) 모바일 앱을 활용한 실시간 흥정요청방법, 관리장치 및 시스템
WO2022177220A1 (ko) 거래 내역을 기반으로 거래 연관 정보 및 거래 행위자의 신용점수를 평가하는 장치, 방법 및 프로그램
CN113077316A (zh) 一种数据展示方法和装置
WO2023068417A1 (ko) 아이템 관련 정보 제공을 위한 전자 장치 및 그 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22940346

Country of ref document: EP

Kind code of ref document: A1