Dynamic Payment Approval System and Method
By configuring payment authorization conditions and storing credential information separately, the system reduces resource consumption and data leakage risks, improving security and efficiency in credit/debit card transactions.
Patent Information
- Application Number
- JP2024508980
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-07-28
- Publication Date
- 2025-07-03
- Estimated Expiration
- 2042-07-28
AI Technical Summary
The increasing number of capture requests for credit/debit card transactions leads to high resource consumption and data leakage risks due to the storage of card information.
A system and method that allow users to configure payment authorization conditions, reducing the need for authorization requests by generating acquisition requests directly when authorization is not required, and storing credential information in a separate vault server independent of the mobile operator's Business Support System.
This approach reduces processing burden on card issuers, enhances security by isolating credential storage, and increases payment processing efficiency.
Smart Images

Figure 0007702569000002 
Figure 0007702569000003 
Figure 0007702569000004
Abstract
Description
Technical Field
[0001] Apparatuses and methods consistent with exemplary embodiments of the present disclosure relate to a payment authorization system.
Background Art
[0002] Generally, a credit / debit card transaction may include an authorization stage (to authorize the transaction) and a capture stage (to withdraw / exchange funds for the transaction). A mobile user can have the option of using credit / debit card transactions for recurring or one-time payments (e.g., bill payments). When the user adds a card for payment, the user can submit card details to the mobile operator, and the mobile operator can store the card details in a storage device. When a payment is required, the mobile operator can send a capture request along with the card details to the card company (i.e., the company that issued the card). The card company can authorize the transaction and the capture request. Upon successful authorization, the card company can request the card host (i.e., the bank account) to debit the amount requested from the user's account and transfer the funds for the amount requested to the mobile operator.
Summary of the Invention
Problems to be Solved by the Invention
[0003] However, as the number of users increases, the number of capture requests (fund requests) increases, resulting in a large cost for authorization processing and a high consumption of resources. For this reason, there is a risk of data leakage of card information stored in the storage device.
Means for Solving the Problems
[0004] According to an embodiment, a system and method are provided that enable a user to configure payment authorization conditions, thereby reducing the number of authorization requests for transactions.
[0005] According to one aspect of the present disclosure, a method for transaction authorization includes receiving, by a payment gateway of a payment platform, an authorization request for a transaction and a security token corresponding to credential information from a business support system (BSS); determining, by the payment gateway, whether transaction authorization is required; generating, by the payment gateway based on the determination that transaction authorization is not required, an acquisition request for withdrawing funds for the transaction; sending, by the payment gateway, the acquisition request to a card issuer corresponding to the credential information; and transferring, by the payment gateway, the funds for the transaction to an operator of the payment gateway.
[0006] According to one aspect of the present disclosure, a system for transaction authorization may include a memory storing instructions, and at least one processor configured to execute instructions including receiving, by a payment gateway of a payment platform, an authorization request for a transaction and a security token corresponding to credential information from a BSS; determining, by the payment gateway, whether transaction authorization is required; generating, by the payment gateway based on the determination that transaction authorization is not required, an acquisition request for withdrawing funds for the transaction; sending, by the payment gateway, the acquisition request to a card issuer corresponding to the credential information; and transferring, by the payment gateway, the funds for the transaction to an operator of the payment gateway.
[0007] According to one aspect of the present disclosure, when executed by at least one processor, a non-transitory computer-readable storage medium causes the at least one processor to receive, from a BSS via a payment gateway of a payment platform, an authorization request for a transaction and a security token corresponding to credential information, cause the payment gateway to determine whether authorization of the transaction is required, based on a determination that authorization of the transaction is not required, cause the payment gateway to generate an acquisition request for withdrawing funds of the transaction, cause the payment gateway to transmit the acquisition request to a card issuer corresponding to the credential information, and store an instruction to transfer the funds of the transaction to an operator of the payment gateway.
[0008] Further aspects are described in part in the following description, become apparent in part from the description, or can be understood by practice of the presented embodiments of the present disclosure.
Brief Description of the Drawings
[0009] The features, advantages, and significance of exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings. In the drawings, like reference numerals denote like elements.
[0010]
Figure 1
Figure 2
Figure 3
Figure 4
Modes for Carrying Out the Invention
[0011] The following detailed description of exemplary embodiments refers to the accompanying drawings. The same reference numerals in different drawings can identify the same or similar elements.
[0012] The above disclosure provides examples and explanations, but is not intended to be exhaustive or to limit implementation to the forms disclosed. Modifications and variations are possible based on the above disclosure or can be obtained from the practice of implementation. Additionally, one or more features or components of one embodiment may be incorporated into another embodiment (or one or more features of another embodiment), or may be combined with another embodiment (or one or more features of another embodiment). In addition, it is understood that in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be executed (at least partially) simultaneously, and the order of one or more operations may be rearranged.
[0013] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods is not limiting. Accordingly, the operations and behaviors of the systems and / or methods have been described herein without reference to specific software code. It is understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.
[0014] Certain combinations of features are recited in the claims and / or disclosed herein, but these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in forms not specifically recited in the claims and / or disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims of the claim set.
[0015] Elements, acts, or instructions used in this book should not be construed as important or essential unless explicitly described. Also, the articles "a" and "an" used in this book are intended to include one or more items and may be used synonymously with "one or more". When only one item is intended, the term "one" or similar language is used. Further, terms such as "has", "have", "having", "include", "including" used in this book are intended to be non-limiting terms. Further, the phrase "based on" is intended to mean "at least partially based on" unless otherwise specified. Further, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.
[0016] FIG. 1 is a diagram of an exemplary environment 100 in which the systems and / or methods described in this book may be implemented. As shown in FIG. 1, the environment 100 may include a user device 110, a platform 120, and a network 130. The devices in the environment 100 can be interconnected by a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. In embodiments, any combination of the elements shown in FIG. 1 above may perform any of the functions and operations described with reference to FIG. 1.
[0017] The user device 110 includes one or more devices that can receive, generate, store, process, and / or provide information related to the platform 120. For example, the user device 110 can include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smartwatch), or a similar device. In some implementations, the user device 110 can receive information from the platform 120 and / or transmit information to the platform.
[0018] The platform 120 includes one or more devices that can receive, generate, store, process, and / or provide information. In some implementations, the platform 120 can include a cloud server or a group of cloud servers. In some implementations, the platform 120 can be modularly designed so that specific software components can be exchanged according to specific needs. Thus, the platform 120 can be easily and / or quickly reconfigured for various applications.
[0019] In some implementations, as illustrated, the platform 120 may be hosted in a cloud computing environment 122. In particular, the implementations described herein are described with the platform 120 being hosted in a cloud computing environment 122, but in some implementations, the platform 120 may not be cloud-based (i.e., implemented outside of a cloud computing environment) or may be partially cloud-based.
[0020] The cloud computing environment 122 includes an environment that hosts the platform 120. The cloud computing environment 122 can provide services such as computing, software, data access, storage, etc., without requiring the end user (e.g., user device 110) to have knowledge of the physical location and configuration of the system and / or device that hosts the platform 120. As shown in the figure, the cloud computing environment 122 may include a group of computing resources 124 (collectively referred to as "computing resources 124" and individually as "computing resource 124").
[0021] The computing resources 124 include one or more personal computers, a group of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 124 can host the platform 120. The cloud resources can include computing instances running within the computing resources 124, storage devices provided within the computing resources 124, data transfer devices provided by the computing resources 124, and so on. In some implementations, the computing resources 124 can communicate with other computing resources 124 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection.
[0022] As further shown in FIG. 1, the computing resources 124 include a group of cloud resources such as one or more applications ("APP") 124-1, one or more virtual machines ("VM") 124-2, virtualized storage ("VS") 124-3, one or more hypervisors ("HYP") 124-4, and so on.
[0023] Application 124-1 includes one or more software applications that can be provided to, or accessed by, user device 110. Application 124-1 can eliminate the need to install and run software applications on user device 110. For example, Application 124-1 can include software related to platform 120 and / or any other possible software provided through cloud computing environment 122. In some implementations, one Application 124-1 can send and receive information with one or more other Applications 124-1 through virtual machine 124-2.
[0024] Virtual machine 124-2 includes a software-implemented machine (e.g., a computer) that runs programs like a physical machine. Virtual machine 124-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree of correspondence of the virtual machine 124-2 to the actual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can execute a single program and support a single process. In some implementations, virtual machine 124-2 can execute on behalf of a user (e.g., user device 110) and manage the infrastructure of cloud computing environment 122, such as data management, synchronization, or long-term data transfer.
[0025] The virtualized storage 124-3 includes one or more storage systems and / or one or more devices that use virtualization technology within a storage system or device of the computing resources 124. In some implementations, in the context of a storage system, the types of virtualization can include block virtualization and file virtualization. Block virtualization can refer to the extraction (or separation) of logical storage from physical storage, thereby enabling access to the storage system regardless of the physical storage or heterogeneous structure. The separation can enable flexibility for the administrator of the storage system that manages the storage for the end user. File virtualization can eliminate the dependency between the data accessed at the file level and the location where the files are physically stored. This can enable optimization of storage usage, server consolidation, and / or non-stop file migration performance.
[0026] The hypervisor 124-4 can provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as the computing resources 124. The hypervisor 124-4 can present a virtual operating platform to the guest operating systems and manage the execution of the guest operating systems. Multiple instances of various operating systems can share the virtualized hardware resources.
[0027] Network 130 includes one or more wired and / or wireless networks. For example, network 130 can include a cellular network (e.g., a fifth generation (5G) network, a long term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or combinations of these or other types of networks.
[0028] The number and arrangement of the devices and networks shown in FIG. 1 are provided as an example. In practice, additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks with an arrangement different from those shown in FIG. 1 may exist. Further, two or more of the devices shown in FIG. 1 may be implemented within a single device, or a single device shown in FIG. 1 may be implemented as multiple distributed devices. Additionally, or alternatively, one set of devices (e.g., one or more devices) in environment 100 may perform one or more functions described as being performed by another set of devices in environment 100.
[0029] FIG. 2 is a diagram of exemplary components of device 200. Device 200 may correspond to user device 110 and / or platform 120. As shown in FIG. 2, device 200 may include a bus 210, a processor 220, a memory 230, a storage component 240, an input component 250, an output component 260, and a communication interface 270.
[0030] Bus 210 includes components that enable communication between components of device 200. Processor 220 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 220 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 220 includes one or more processors that can be programmed to execute functions. Memory 230 includes random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 220.
[0031] Storage component 240 stores information and / or software related to the operation and use of device 200. For example, storage component 240, along with a corresponding drive, may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium. Input component 250 includes components that enable device 200 to receive information from user inputs (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone), among others. Additionally, or alternatively, input component 250 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output component 260 includes components that provide output information from device 200 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).
[0032] The communication interface 270 includes components such as a transceiver (e.g., a transceiver and / or separate receivers and transmitters) that enable the device 200 to communicate with other devices by means of a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. The communication interface 270 can enable the device 200 to receive information from another device and / or provide information to another device. For example, the communication interface 270 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.
[0033] The device 200 can execute one or more of the processes described herein. The device 200 can execute these processes in response to a processor 220 that executes software instructions stored by a non-transitory computer-readable medium such as the memory 230 and / or the storage component 240. The computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space spanning multiple physical storage devices.
[0034] The software instructions can be read into the memory 230 and / or the storage component 240 from another computer-readable medium or from another device through the communication interface 270. The software instructions stored in the memory 230 and / or the storage component 240, when executed, can cause the processor 220 to execute one or more of the processes described herein.
[0035] Additionally, or alternatively, instead of software instructions, or in combination with software instructions, hardwired circuitry may be used to perform one or more of the processes described in this document. Accordingly, the implementations described in this document are not limited to any particular combination of hardware circuitry and software.
[0036] The number and arrangement of components shown in FIG. 2 are provided as an example. In practice, device 200 may include additional components, fewer components, different components, or components arranged differently from those shown in FIG. 2. Additionally, or alternatively, one set of components of device 200 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 200.
[0037] Exemplary embodiments provide a method and system that enable a user of a payment authorization platform to configure the conditions under which payment authorization is required, such that some specific user groups do not require actual authorization (i.e., some authorization requests can be pre-approved, or the authorization step can be bypassed and proceed directly to the acquisition step, and the system can directly proceed to generate an acquisition request). Further, credential information (e.g., card information, user credentials, etc.) can be stored in a separate storage (e.g., a vault server, etc.) independent of the mobile operator (i.e., when a user provides the credential information to the mobile operator for storage for future transactions, the credential information is stored in the aforementioned separate storage). Accordingly, the credential information can be stored in a storage device independent of the mobile operator's Business Support System (BSS) (also referred to as a business management system), and since the credential information is not managed by the BSS, information security is improved. Further, the processing burden on the card issuer when authorizing an acquisition request (i.e., a request to withdraw funds from a card host such as a bank account) can be reduced, and the efficiency of payment processing is increased.
[0038] Figure 3 is a diagram of a payment authorization system according to an embodiment. System 300 can communicate with user device 301. System 300 may include a BSS 302 and a payment platform 304. BSS 302 may include a Billing Management Module (BMM) 303. The payment platform 304 may include a credentials storage device 306 (e.g., a vault server) and a payment gateway 308. System 300 can communicate with a payment system 310 that includes, for example, a proprietary payment system 312 and a third-party payment system 314. The payment system 310 and / or other components of system 300 can communicate with a card issuer 320 that includes, for example, a proprietary card issuer 322 and a third-party card issuer 324. The proprietary payment system and the proprietary card issuer may refer to a payment system and a card issuer within the same company, the same partnership, or the same operating system of the operator of system 300 (e.g., system company X may operate system 300, issue cards corresponding to system company X, and operate a payment system 312 corresponding to the cards of system company X). The third-party payment system and the third-party card issuance may refer to a payment system and a card issuer operated by a company or system that is separate from, different from, or not corresponding to system 300 (e.g., system company X may operate system 300, company Y may issue cards used in transactions, and company Y may operate a payment system 314 for transactions with the cards issued by company Y).
[0039] In an exemplary embodiment of the process of adding credential information to system 300, a user of user device 301 can submit a request to add credential information to BSS 302, and BSS 302 can present a user interface (UI) page for entering the credential information to the user on user device 301. The user of user device 301 can enter the credential information (e.g., card number, expiration date, billing address, customer verification value (CVV), etc.) into the UI page, and the credential information can be sent directly from user device 301 to the credential storage device 306 of payment platform 304, so that the credential information is stored separately and independently of BSS 302. The credential storage device 306 may be configured to generate a security token based on the stored credential information and provide the security token to user device 301. In some embodiments, upon receiving a request from the user to add credential information, BSS 302 can direct the user to the payment platform 304, and the payment platform 304 can generate a UI for entering the credential information. The entered credential information can be stored directly in the credential storage device 306 of the payment platform 304. By doing so, the BSS operator cannot directly access the credential information.
[0040] Following the start of credential information (i.e., generation of a security token), to initiate a transaction, the BMM 303 of the BSS 302 can receive an authorization request and a security token from the user device 301 and store the security token in the BSS 302 (e.g., in the storage device 390 of the BSS 302). The BSS 302 can send the authorization request and the security token to the payment gateway 308. The payment gateway 308 can generate a request to receive credential information corresponding to the authorization request and the security token from the credential storage device 306. The payment platform 304 (i.e., by the stand-alone processor and / or the processor of the credential storage device 306) can determine whether authorization is required for the transaction based on the authorization configuration profile associated with the credential and the authorization parameters set by the user (as described in detail below). If it is determined that authorization is required, the credential storage device 306 can provide the credential information to the payment gateway 308 or provide an instruction to the payment gateway 308 that authorization is not required for the transaction. If authorization is required, the payment gateway 308 can communicate with the settlement system 310 and the card issuer 312 to resolve the transaction, as described in detail below. If authorization is not required, the payment gateway 308 can complete the transaction without obtaining authorization.
[0041] In an exemplary embodiment of the process of configuring authorization conditions, access to the BSS system 302 can be provided to the user. The BMM 303 of the BSS 302 can generate a UI and present it to the user through the user device 301. This UI can include a plurality of input fields configured to receive an input from the user specifying parameters for obtaining requested authorization. The BSS 302 can generate a configuration profile based on the authorization parameters selected by the user. [Table 1]
[0042] Table 1 shows an example of a configuration profile of authorization parameters according to an embodiment. Exemplary parameters may include a card issuer. For example, the card may be a card issued by a first group of card issuers (e.g., an in-company card, a proprietary card, or a card issued by a mobile operator of BSS302), and a card issued by a second group of card issuers (e.g., an inter-company card, a card issued by a third party). Exemplary parameters may include the type of card. For example, the type of card may be a credit card, a debit card, etc. Exemplary parameters may include the transaction amount, and the user can set a predetermined transaction amount, and authorization may not be required if the transaction amount is below it. Exemplary parameters may include the transaction occurrence frequency. For example, the user can set to request authorization when the transaction first occurs and not request authorization when the transaction occurs thereafter (e.g., when a non-first transaction occurs). Exemplary parameters may include the security token update status. For example, the user can request authorization when the update of the security token fails. The security token update may include an updated token based on the updated credential information. Exemplary parameters may include the security token update result. For example, the user can request authorization for a transaction when the security token is updated. In the example shown in Table 1, the system is configured so that the user does not request authorization when the issuer card is in-company, the card is a credit card, the transaction amount is less than 30,000 yen, the transaction has been authorized before, the last card has been updated properly, and the update is not associated with a security token update.
[0043] In another exemplary embodiment of the process for authorizing a payment (e.g., monthly bill payment to a mobile operator), when a payment is required, BMM303 can send an authorization request including a security token to the payment gateway 308 of the payment platform 304. The payment gateway 308 can send the security token to the credential storage device 306 to receive the credential information for the transaction. Upon receiving the credential information for the transaction, the payment gateway 308 can obtain an authorization configuration profile (e.g., a profile such as Table 1) from storage (e.g., from the storage of the user device 301, from the storage of BMM302, from the credential storage device 306, etc.), and based on the credential information and the authorization configuration profile, determine whether authorization is required.
[0044] If authorization is not required, the payment gateway 308 can generate an acquisition request based on the credential information and send the acquisition request to the card issuer 320. Upon receiving the acquisition request, the card issuer 320 can commit to the amount requested in the acquisition request, debit the amount of money requested for the transaction from the user's bank account, and request the card host (e.g., the bank account) to transfer the requested amount to the mobile operator (e.g., the operator of BMM302 and the payment platform 304).
[0045] If authorization is required, the payment gateway 308 can generate a formal authorization request and a formal acquisition request based on the credential information and send those requests to the card issuer 320 (the payment gateway 308 can determine the corresponding card issuer based on the credential information). The payment gateway 308 can send a formal authorization request and a formal acquisition request to the settlement system 310 of the corresponding card company (e.g., the proprietary card company 312, the third-party card company 314, etc.). The payment gateway 308 can determine the card company based on the authorization request and the service ID provided by the BSS302 along with the security token. The settlement system 310 can transfer the service ID to the card issuer 320. The card issuer 320 can authorize the transaction and the acquisition request based on the provided credential information and the information stored in the card issuer 320 system. The card issuer 320 can send a notification indicating the result of the authorization (e.g., success, failure, timeout, hold, etc.) to the user device 301 via the payment gateway 308.
[0046] Figure 4 is a flowchart of a method for transaction authorization according to an embodiment. In operation 402, the system can receive, from the BSS, an authorization request for a transaction and a security token corresponding to the credential information by the payment gateway of the payment platform. In operation 404, the system can determine, by the payment gateway, whether transaction authorization is required. Based on the determination that transaction authorization is not required, in operation 406, the system can generate, by the payment gateway, an acquisition request to withdraw funds for the transaction, and in operation 408, the system can send, by the payment gateway, the acquisition request to the card issuer corresponding to the credential information, and in operation 410, the system can transfer, by the payment gateway, the funds for the transaction to the operator of the payment gateway.
[0047] In an embodiment, any one of the operations or processes in FIGS. 3-4 can be implemented by any one of the elements shown in FIGS. 1 and 2 or using any one of the elements shown in FIGS. 1 and 2.
[0048] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementation to the forms disclosed as such. Modifications and changes are possible in light of the foregoing disclosure or can be obtained from practice of the implementation.
[0049] Some embodiments may relate to a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, any one or more of the components described above may be implemented as instructions (and / or may include at least one processor) stored in a computer-readable medium and executable by at least one processor. The computer-readable medium may include a computer-readable non-transitory storage medium (s) having computer-readable program instructions for causing a processor to perform operations.
[0050] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures in which instructions are recorded in grooves, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed to be a signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire, which are all transient signals.
[0051] The computer-readable program instructions described in this book can be downloaded from a computer-readable storage medium to respective computing / processing devices or to an external computer or an external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium in each computing / processing device.
[0052] The computer-readable program code / instructions for performing the operations may be in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of object-oriented programming languages such as Smalltalk and C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may utilize the state information of the computer-readable program instructions to execute the computer-readable program instructions to personalize the electronic circuit and perform aspects or operations.
[0053] These computer-readable program instructions are provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein comprises an article of manufacture including instructions for implementing the aspects of the functions / acts specified in one or more blocks of the flowchart and / or block diagram.
[0054] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram.
[0055] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of one or more executable instructions for implementing the specified logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may actually be executed simultaneously, or substantially simultaneously, or the blocks may sometimes be executed in the reverse order depending on the related functions. Also, note that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks of the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified function or action, or that performs a combination of dedicated hardware and computer instructions.
[0056] It will be apparent that the systems and / or methods described in this document may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement these systems and / or methods is not limiting. Accordingly, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.
Claims
**Claim 1** Receiving, by a payment gateway of a payment platform, from a business support system (BSS), a request for authorization of a transaction and a security token corresponding to credential information; Determining, by the payment gateway, whether authorization of the transaction is required based on the credential information and an authorization configuration profile corresponding to the credential information; Based on a determination that authorization of the transaction is not required, Generating, by the payment gateway, an acquisition request for withdrawing funds for the transaction; Sending, by the payment gateway, the acquisition request to a card issuer corresponding to the credential information to cause the card issuer to request the card host to transfer the funds for the transaction to an operator of the payment gateway; Including; Determining whether authorization of the transaction is required includes retrieving, by the payment gateway, an authorization configuration profile corresponding to the credential information, the authorization configuration profile including at least one authorization parameter; The payment gateway is configured to determine whether authorization of the transaction is required based on the at least one authorization parameter; The authorization parameter includes a security token update result indicating whether there is an update of the security token; A method for authorizing a transaction, wherein the payment gateway determines that authorization of the transaction is not required based on the security token update result indicating that the security token has not been updated. **Claim 2** Generating, by a credential storage device of the payment platform, the security token corresponding to the credential information; The method according to claim 1, further including sending, by the credential storage device, the security token to a user device. **Claim 3** The method according to claim 2, wherein the BSS receives the authorization request and the security token from the user device. **Claim 4** The method according to claim 2, further including storing, by the credential storage device, the credential information corresponding to the security token so that the credential information is stored separately and independently from the BSS.
5. The approval parameter includes a predetermined transaction amount, The payment gateway determines that approval of the transaction is not required based on the amount of the transaction being less than the predetermined transaction amount, according to the method of claim 1.
6. The approval parameter includes information indicating whether a transaction using a specific card issued by the card issuer is a first occurrence or not, The payment gateway determines that approval of the transaction is not required based on the transaction occurrence of the transaction not being a first occurrence, according to the method of claim 1.
7. A memory for storing instructions, Instructions for receiving, by a payment gateway of a payment platform, a transaction approval request and a security token corresponding to credential information from a business support system (BSS), Instructions for the payment gateway to determine whether approval of the transaction is required based on the credential information and an approval configuration profile corresponding to the credential information, Based on the determination that approval of the transaction is not required, Instructions for the payment gateway to generate an acquisition request for withdrawing funds for the transaction, Instructions for the payment gateway to send the acquisition request to the card issuer to request the card issuer corresponding to the credential information to transfer the funds of the transaction to the operator of the payment gateway by the card host, At least one processor configured to execute, Comprising, The at least one processor is further configured to execute instructions for the payment gateway to determine whether approval of the transaction is required by retrieving an approval configuration profile corresponding to the credential information, the approval configuration profile including at least one approval parameter, The payment gateway is configured to determine whether approval of the transaction is required based on the at least one approval parameter, The approval parameter includes a security token update result indicating whether there is an update of the security token, A system for transaction approval, wherein the payment gateway determines that approval of the transaction is not required based on the security token update result indicating that the security token has not been updated.
8. The at least one processor is further configured to generate, by the credentials storage device of the payment platform, a security token corresponding to the credentials information; and send, by the credentials storage device, the security token to a user device. The system according to claim 7 is configured to execute the commands. **Claim 9** The system according to claim 8, wherein the BSS receives the authorization request and the security token from the user device. **Claim 10** The at least one processor is further configured to store, by the credentials storage device, the credentials information corresponding to the security token so that the credentials information is stored separately and independently from the BSS. The system according to claim 8 is configured to execute the commands. **Claim 11** The authorization parameter includes a predetermined transaction amount, and the payment gateway determines that authorization of the transaction is not required based on the fact that the amount of the transaction is less than the predetermined transaction amount. The system according to claim 7 is configured to execute the commands. **Claim 12** The authorization parameter includes information indicating whether a transaction using a specific card issued by the card issuer is a first-time or non-first-time occurrence, and the payment gateway determines that authorization of the transaction is not required based on the fact that the transaction occurrence is non-first-time. The system according to claim 7 is configured to execute the commands. **Claim 13** When executed by at least one processor, the at least one processor is caused to receive, by a payment gateway of a payment platform, an authorization request for a transaction and a security token corresponding to credentials information from a business support system (BSS); determine, by the payment gateway, whether authorization of the transaction is required based on the credentials information and an authorization configuration profile corresponding to the credentials information; based on a determination that authorization of the transaction is not required, generate, by the payment gateway, an acquisition request for withdrawing funds for the transaction. Store an instruction to cause the card issuer corresponding to the credential information to send the acquisition request to the card issuer in order to cause the card host to transfer the funds of the transaction to the operator of the payment gateway by the payment gateway. The at least one processor further causes the payment gateway to determine whether authorization of the transaction is required by retrieving an authorization configuration profile corresponding to the credential information, the authorization configuration profile including at least one authorization parameter. The authorization parameter includes a security token update result indicating whether there is an update of the security token. A non-transitory computer-readable storage medium, wherein the payment gateway determines that authorization of the transaction is not required based on the security token update result indicating that the security token has not been updated.
14. The instruction, when executed, further causes the at least one processor to determine whether authorization of the transaction is required by retrieving an authorization configuration profile corresponding to the credential information by the payment gateway, the authorization configuration profile including at least one authorization parameter. The storage medium according to claim 13, wherein the payment gateway is configured to determine whether authorization of the transaction is required based on the at least one authorization parameter.
Citation Information
Patent Citations
Settlement server, settlement system, settlement method, and settlement program
JP2011210171A
Program, device, computer, and payment system
JP2022105930A
Terminal type identification in interaction processing
JP2022518833A
Log-on service providing credential level change without loss of session continuity
US20070101418A1
Electronic money transfer service
US20130060689A1