WO2015040204A1

WO2015040204A1 - An online payment enablement network and method

Info

Publication number: WO2015040204A1
Application number: PCT/EP2014/070087
Authority: WO
Inventors: Kieron Guilfoyle
Original assignee: Snapcount Limited
Priority date: 2013-09-23
Filing date: 2014-09-22
Publication date: 2015-03-26

Abstract

A transaction processing enablement network (100, 110) receives from a merchant system (201) or a payment service provider (PSP) system (202) a customer code such as a PIN which has been presented by a customer for a transaction, and also transaction data. It generates a corresponding PAN for the customer code, and sends to the merchant (202) or PSP system (202) the PAN and transaction data sufficient for a debit or credit scheme network transaction. The enablement network (100, 110) subsequently receives from the scheme network (203) an authorisation request, processes said request, and responds to the scheme network.

Description

"An Online Payment Enablement Network and Method"

Introduction

The invention relates to technical and functional aspects of transaction processing.

The development of alternative payment methods has increased as online commerce continues to grow. To date the primary method for transacting has been to use a payment card such as a debit or credit card.

There is a growing trend globally for customers wishing to transact with cash or their bank account directly online and a number of solution providers such as Paysafecard and UKash have emerged which require the customer to purchase a Payment Identity Number (PIN) in a convenience store and then enter the PIN at the online merchant's shopping cart. Consumers choose these systems for a combination of reasons which include fear of fraud, lack of access of a payment card or anonymity. However, these systems require technical integration by the solutions providers to each individual merchant to acquire the payment outside of standard protocols and a separate funds settlement system. This is because the number which is entered by the customer is not in the industry- standard 16-digit Scheme based (e.g. VISA, MasterCard) Primary Account Number (PAN) format and not processed by such scheme settlement systems. As a result these systems are costly and appeal to a very narrow segment of online merchants.

Another issue is that the traditional payment card model is challenged by the fact that in many countries credit card usage is decreasing as debit card usage replaces it. An issue in using debit cards online is that if they are compromised and used fraudulently then funds are debited direct from a consumer's bank account in real time thus creating significant problems as accounts are drained of funds.

The invention is directed towards providing a more versatile system and method for transaction processing. Another object is to achieve a faster transaction time, with less electronic message traffic communicated between network elements. Another objective is to minimise or avoid technical update requirements to merchant systems for implementation or modification of a system by utilising existing acquiring and settlement processes. Summary of the Invention

According to the invention, there is provided a transaction processing enablement network comprising digital processors and communication circuits adapted to:

receive from a merchant system or a payment service provider PSP system a customer code which has been presented by a customer for a transaction, and also transaction data,

provide a corresponding PAN for the customer code, and send to the merchant or PSP system the PAN and transaction data sufficient for a scheme network transaction, and to

subsequently receive from the scheme network an authorisation request, process said request, and respond to the scheme network.

In one embodiment, the enablement network is adapted to, after authorisation, map a transaction balance of the PAN back to the customer code and vice versa.

In one embodiment, the enablement network comprises and is adapted to maintain a database of transaction logs for both the customer and the merchant.

In one embodiment, the enablement network is adapted to generate and handle multiple PANs for a single customer code or multiple customer codes for a single PAN. Preferably, the network is adapted to decrement after each transaction a customer code financial value.

In one embodiment, the enablement network comprises:

a first logical group of 1 to N servers for interfacing with the merchant and/or PSP system, and

a second logical group of 1 to M servers for generating the PANs and interfacing with the scheme network.

In one embodiment, the second group interfaces with the first group, and the second group is isolated from merchant and PSP systems. In one embodiment, the enablement network is adapted to generate a master PAN linked to one or more related customer codes, and to use the master PAN to submit to the scheme network a batch of transactions for a single transaction process through the scheme network, or submit the master PAN to the scheme network for each transaction where batching is not in place. In one embodiment, the enablement network is adapted to manage issuance of said customer codes. Preferably, the customer code is associated with a fixed maximum value. In one embodiment, the enablement network is adapted to verify a received customer code upon receipt. In one embodiment, said network comprises a first platform adapted to connect directly to a PSP system to map customer codes to PANs generated by a second platform of said network and to send PANs through the PSP for authorisation and settlement by the scheme. In one embodiment, said first platform is adapted to have a secure connection to a PSP system, to point- of-sale terminals, or to servers linked to such terminals, and to the second platform and provide and maintain customer and merchant code and transaction data.

In one embodiment, said second platform is adapted to maintain connectivity with an Application Protocol Interface to a gateway of a scheme network in order to settle payment card transactions. Preferably, the second platform is adapted to create and maintain said PANs, and the first platform is connected directly to the second platform through a published set of Application Protocol Interfaces.

In one embodiment, the network is adapted to perform customer registration in which customer data is validated by sending a short code that the customer then needs to input back into the network, in order to validate themselves for security and identification.

In one embodiment, said network is adapted to provide a password-protected mobile application or website to allow customer entry of their customer code, and to return a safe code that acts as an additional security validation such that both the customer code and the safe code are required to be inputted by a customer to allow the transaction to proceed.

In one embodiment, said network is adapted to return to a merchant system or customer device a new format of the customer code for additional security.

In one embodiment, said enablement network is adapted to treat each received customer code according to a pre-set rule set applicable to the particular merchant. Preferably, the enablement network is adapted to perform a pre-transaction approval without accessing a scheme network. In one embodiment, the enablement network is adapted to perform said approval using a financial balance associated with a customer and stored internally within the enablement network.

In one embodiment, the enablement network is adapted to merge customer codes. Preferably, the enablement network is adapted to perform the following steps to merge customer codes:

a balance for a customer code is merged with another balance, giving the consumer consolidated funds and potentially an extension on expiry when merging codes,

the sender customer code is marked as used or transferred which renders the said code as unusable and this code and any corresponding PAN balance are reduced to zero, and

the receiving code and corresponding PAN are accordingly credited.

In one embodiment, the enablement network is adapted to generate a safe code, to use both the safe code and a customer code for interfacing with an external system for added security, and to merge combinations of safe codes and customer codes.

In one embodiment, the enablement network is adapted to create a master PAN specific to a merchant and to map a plurality of customer codes back to said master PAN.

In one embodiment, the enablement network first platform is adapted to integrate to a Payment Service Provider via specific Application Protocol Interfaces that include creation of a secure connection, building of forms, interchange of specific messaging protocols and protection of stored data, and in which the integration includes merchant rules that apply to merchant transactions and logic for these rule sets is maintained and operated on the first platform with response messaging to the PSP.

In one embodiment, the enablement network is adapted to execute a rules configurator to allow a merchant system to configure how they wish their transactions to be handled, including rules that allow transactions to enter a pending status until such time as certain thresholds have been met.

In one embodiment, the thresholds include the following parameters: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters. In one embodiment, the enablement network is adapted to manage a unique merchant PAN for use with multiple customer codes and transactions. Preferably, the enablement network is adapted to return the PAN to a PSP for payment processing, and if the merchant has specified that full authorization is to be batched, multiple customer codes are mapped to the pre-generated PAN before it is sent to the PSP for batch authorization. In one embodiment, the enablement network is adapted to, if a customer makes purchases at multiple merchants, map the customer code to multiple pre-generated PANs.

In one embodiment, the enablement network is adapted to, at a point of transaction, debit a surcharge from a customer code balance in excess of the transaction amount, or a loyalty bonus credited to the customer code, as per the merchant's pre-set settings.

In another aspect, the invention provides a transaction processing method performed by an enablement network comprising digital processors and communication circuits, a merchant system, a PSP system, and a gateway to a scheme network, the method comprising the steps of:

the enablement network receiving from the merchant system or the PSP system a customer code which has been presented by a customer for a transaction, and also transaction data,

the enablement network providing a corresponding PAN for the customer code, and sending to the merchant or the PSP system the PAN and transaction data sufficient for the scheme network transaction, and

the enablement network subsequently receiving from the scheme network an authorisation request, processing said request, and responding to the scheme network.

In one embodiment, the enablement network, after authorisation, maps a transaction balance of the PAN back to the customer code or vice versa. In one embodiment, the enablement network comprises and maintains a database of transaction logs for both the customer and the merchant. In one embodiment, the enablement network generates and handles multiple PANs for a single customer code or multiple customer codes for a single PAN.

In one embodiment, the enablement network decrements after each transaction a customer code financial value. In one embodiment, the enablement network generates a master PAN linked to one or more related customer codes, and uses the master PAN to submit to the scheme network a batch of transactions for a single transaction process through the scheme network, or submit the master PAN to the scheme network for each transaction where batching is not in place. Preferably, the enablement network manages issuance of said customer codes. In one embodiment, the customer code is associated with a fixed maximum value. In one embodiment, the enablement network verifies a received customer code upon receipt. In one embodiment, the enablement network performs customer registration in which customer data is validated by sending a short code that the customer then needs to input back into the network, in order to validate themselves for security and identification.

In one embodiment, the enablement network provides a password-protected mobile application or website to allow customer entry of their customer code, and returns a safe code that acts as an additional security validation such that both the customer code and the safe code are required to be inputted by a customer to allow the transaction to proceed.

In one embodiment, the enablement network returns to the merchant system or customer device a new format of the customer code for additional security. In one embodiment, said enablement network treats each received customer code according to a pre- set rule set applicable to the particular merchant.

In one embodiment, the enablement network performs a pre-transaction approval without accessing a scheme network. Preferably, the enablement network performs said approval using a financial balance associated with a customer and stored internally within the enablement network. In one embodiment, the enablement network merges customer codes.

In one embodiment, the enablement network performs the following steps to merge customer codes:

the sender customer code is marked as used or transferred which renders the said code as unusable and this code and any corresponding PAN balance are reduced to zero, and the receiving code and corresponding PAN are accordingly credited.

In one embodiment, the enablement network generates a safe code, uses both the safe code and a customer code for interfacing with an external system for added security, and merges combinations of safe codes and customer codes. Preferably, the enablement network creates a master PAN specific to a merchant and maps a plurality of customer codes back to said master PAN.

In one embodiment, the enablement network executes a rules configurator to allow a merchant system to configure how they wish their transactions to be handled, including rules that allow transactions to enter a pending status until such time as certain thresholds have been met. In another embodiment, the thresholds include the following parameters: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters.

In one embodiment, the enablement network manages a unique merchant PAN for use with multiple customer codes and transactions. In one embodiment, the enablement network returns the PAN to the PSP for payment processing, and if the merchant has specified that full authorization is to be batched, multiple customer codes are mapped to the pre-generated PAN before it is sent to the PSP for batch authorization. In another embodiment, if a customer makes purchases at multiple merchants, the enablement network maps the customer code to multiple pre-generated PANs. In one embodiment, the enablement network, at a point of transaction, debits a surcharge from a customer code balance in excess of the transaction amount, or a loyalty bonus credited to the customer code, as per the merchant's pre- set settings. Preferably, the enablement network manages transfer of money between two persons by changing association of customer codes to persons.

In one embodiment, the enablement network manages said transfer by: receiving from a sender with a customer code a request to send the customer code to a recipient, and unique data identifying the recipient, validating the request, in which the following must be valid:

an account of the sender has a financial balance, the recipient has an account registered with the enablement network, the sender and the recipient accounts are within transaction amount limits for time periods,

if the request is valid removing the selected customer code from the sender account, and saving it against the recipient account, and

sending a message to the sender to indicate that the request was successful, and sending a message to the recipient to inform them that they have received a customer code. In a further aspect, the invention provides a computer readable medium comprising software code adapted to perform the steps of a method as defined above in any embodiment when executing on a digital processor.

Detailed Description of the Invention

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which :-

Figs. 1 and 2 are "ladder" diagrams illustrating the steps in detail of two methods of operation of an enablement network of the invention; and

Figs. 3 to 6 are diagrams illustrating different modes of operation of the enablement network. The main elements involved in a transaction process of various embodiments are as follows. The customer has a customer code, which in these examples is a PIN. This may be in printed or digital form and is purchased in a physical store or online. The customer uses a computer or smartphone ("device") 200, and the merchant has a merchant server 201. A payment gateway or Payment Service Provider (PSP) 202 is a third party system that securely routes payment card transactions from a merchant to an acquiring bank and a card scheme 203.

An enablement network of the invention has an "OPEN" enablement platform 100 and a processor 110. The platform 100 comprises a group of 1-N servers, and the processor 110 comprises a group of 1-M servers. The enablement platform 100 communicates directly with the PSP 202 in order to map PINs issued on its servers to PANs which it generates via a separate Processor 110 (see below). It also facilitates secure connections to both the PSP servers 202 and to cash loading network servers as well as maintaining all customer and merchant transaction data. It also interfaces with acquirer bank systems. The servers are in one embodiment conventional in hardware terms, but are adapted by programming to perform the operations for transaction processing of the invention, and the number of servers is dependent on the expected volume of transactions and consequent throughput of messages. In other embodiments the servers have firmware provide by FGPAs or ASICs for example. The enablement network Processor 110 is a platform which maintains connectivity to the scheme network gateways in order to settle payment card transactions. It also creates and maintains PANs. The OPEN enablement platformlOO connects directly to the Processor 110 through a published set of Application Protocol Interfaces. The following is the sequence of messages and operations for a transaction to be performed using the enablement network of the invention.

1. A customer registers a PIN that they have previously purchased either online, in App or via a physical store. Each PIN has a fixed value (in this example€100) but can be used multiple times in multiple online merchants until the balance is reduced to zero. These

PINs are more secure than standard credit or debit cards as they are only limited to the value of the balance at any point in time.

The customer receives a safe code which is an additional identifier, unique to the PIN, which must be used to make a payment transaction. Both PIN and safe code details are stored in the customer's account, in addition to current balance and any transactions made.

A customer may have multiple PINs.

2. The customer enters the PIN and safe code at the online merchant's server 201 shopping cart when prompted. In this example the value of the order is€20.

3. The online merchant server 201 sends the PIN and safe code to the PSP 202 with details of the amount, the merchant ID, and the value of the transaction i.e.€20.

4. The PSP 202 sends on the same detail as in Step 3 to the platform 100 which checks the validity of the PIN and safe code on its own servers including the current balance. 5. If the balance exceeds the amount on the PIN then the platform 100 requests from the processer 110 a scheme -based Primary Account Number (PAN) to be set up on the processor 110 for the value of the original PIN i.e.€100. The processor 110 is also connected to the scheme network gateway 203 for processing PANs in the normal manner. The scheme network is the network used for conventional card transaction processing. An advantageous aspect of the invention is that the enablement network can avoid need to replicate its functionality by interfacing with the scheme without affecting conventional operations of the scheme.

6. The processor 110 returns to the platform 100 a PAN, CVV2/CVC, Expiry date and whatever other data fields are required for a scheme debit/credit transaction.

7. The platform 100 sends the full PAN details to the PSP 202.

8. The PSP 202 informs the merchant server 201.

9. The merchant server 201 informs the user device 200.

10. The PSP 202 sends the complete transaction details to the acquiring bank server 203 for authorisation.

11. The acquiring bank server 203 sends the transaction to the scheme network.

12. The scheme network routes the transaction to the processor 110 and issuing bank of the PAN.

13. The processor 110 checks the details of the transaction and authorises the transaction against the PAN created in Step 6.

14. The processor 110 decrements the balance of the transaction against the PAN and the PAN and transaction details are communicated to the platform 100.

15. The Platform 100 maps the remaining balance of the PAN back to the original PIN and maintains a transaction log for both the customer and merchant. The PIN balance may be decremented on approval of the transaction, before the PAN is decremented.

The customer may now decide to shop at another online merchant (Merchant B), and so enters their PIN and safe code as described above. In this example the value of the transaction is€10. The PSP sends the PIN and transaction value for verification to the Platform 100. The platform 100 recognises that there is a balance of €80 left on the PIN and an existing PAN and the platform 100 sends details of the matching PAN plus all other details required to process the transaction. The PSP performs the same process as per step 10. Steps 12 - 15 are then repeated and the resulting balance on the PIN is€70. The customer registration process is that their mobile phone number or email is validated by sending a short code that they then need to input back into the mobile application or website in order to be validated for security. On purchasing a PIN the customer may also be required to enter that PIN into a password-protected mobile application or website having logged into their account. Once a PIN is entered the platform 100 returns a safe code which can be a short code that acts as an additional security code for the PIN such that both the PIN and safe code would be required to be entered at a merchant's shopping cart in order to allow the purchase transaction to proceed. This two-factor identification process ensures an even higher level of security for both the online merchant and the customers as it drastically decreases the likelihood of fraud and allows the platform to track limits and customer behaviour.

Referring to Fig. 2 in an alternative embodiment a rule set is implemented by the enablement network to perform operations which add security and/or reduce cost, and/or add flexibility. The following are the major messages and operations.

1. A customer for the first time presents a PIN that they have previously purchased either online, in App or via a physical store. Each PIN has a fixed value (in this example€100) but can be used multiple times in multiple online merchants until the balance is reduced to zero.

2. The customer enters the PIN at the online merchant's (Merchant A) shopping cart when prompted. In this example the value of the order is€20.

3. The online merchant sends the PIN to the PSP 202 with details of the amount, the merchant ID, and the value of the transaction i.e.€20.

4. The platform 100 checks the validity of the PIN on its own servers including the current balance. If the balance of the transaction exceeds the amount on the PIN then the platform 100 makes a call to the processer 110 requesting a Primary Account Number (PAN) to be set up on the processor 110 for the value of the original PIN i.e.€100. The processor 110 is also connected to the scheme network gateway 203 for processing PANs in the normal manner.

5. The Processor 110 sends the PAN details to the platform 100.

6. The platform 100 checks a merchant rule set to establish if a surcharge/loyalty bonus should be applied to the transaction and adjusts the balance of the transaction accordingly. If the merchant rule set has set parameters or combinations of parameters for batching transactions below a certain value until certain rule based thresholds are met then the transaction is held in a queue and batched pending release.

7. For each of these pending transactions (assuming they are from PINs being used the first time) the processor 110 may on the instructions of the platform 100 creates an individual PAN, CVV2/CVC, expiry date and whatever other data fields are required for a scheme debit/credit transaction. Alternatively, no PAN is generated, but the transaction is recorded against the PIN and confirmed to the PSP without creating a PAN. Additionally the PAN and account details are matched in the platform 100 from PINs that have already had a PAN allocated from a previous transaction.

8. On reaching the required parameter or combination of parameters threshold for batch processing the platform 100 allocates a master PAN for that specific online merchant account and transfers the balance of each individual PAN created in the pending queue. Each individual existing PAN will have their specific transaction value decremented from their balance by the platform 100, if this has not already been done. The platform 100 then sends the full master PAN details plus the combined value of the online merchant' s transactions that were in the pending queue to the PSP.

9. The PSP sends the complete transaction details to the acquiring bank 203 for authorisation. The acquiring bank 203 sends the transaction to the scheme network.

10. The scheme network routes the transaction to the processor 110.

11. The processor 110 checks the details of the transaction and authorises the transaction against the master PAN created in Step 8.

12. The processor 110 decrements the balance of the transaction against the PAN.

13. The processor 110 shares PAN and transaction details with the platform 100.

14. The platform 100 maps the remaining balance of both individual and master PANs and maintains a transaction log for both the customer and the merchant.

The merchant registration process can be via the PSP or directly.

A merchant can also choose to create a master PAN specific to that merchant such that all PIN transactions are mapped directly to this PAN on a continuous basis. This may be a requirement of the platform 100.

To perform the operations above the platform 100 integrates to the PSP via specific Application Protocol Interfaces (APIs) that include the creation of a secure connection, the building of forms, the interchange of specific messaging protocols and the protection of stored data. Specific to the integration is the setting up of merchant transaction rules that will apply to merchant transactions such as crediting or debiting charges to a transaction or value/volume thresholds for batching transactions. The logic for these rule sets is maintained and operated on the platform 100 with response messaging to the PSP.

In one scenario, an online merchant 201 wishes to accept payments via the platform 100 issued PINs. By way of registration forms the merchant enrols for the service. In doing so they set up specific rules as to how their transactions should be treated. For example, the merchant can decide to add a surcharge automatically to each transaction either as a fixed value or as a percentage of the transaction. Alternatively the merchant can choose to credit a customer account with value in the same manner. The merchant can also configure how they wish their transactions to be handled through a rules-based configurator that allows transactions to enter a pending status until such time as certain thresholds have been met. These thresholds will include the following parameters but are not limited to: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters. Once a threshold has been met the platform 100 will carry out a process whereby each PIN is mapped to a specific PAN (not a requirement where no PAN already exists) or the merchant is issued a master PAN (where one does not already exist) which collates all of the PINs onto one PAN which is then send for authorisation.

Once the merchant completes the registration the rules-based logic is stored on the platform 100 awaiting transaction data from the PSP. Where the platform 100 is not connected to an online merchant's PSP the merchant can connect directly to the platform 100. This integration is via specific Application Protocol Interfaces (APIs) that include the creation of a secure connection to the platform 100, the building of forms, the interchange of specific messaging protocols and the protection of stored data. Specific to the integration is the setting up of merchant transaction rules that will apply to merchant transactions such as crediting or debiting charges to a transaction or value/volume thresholds for batching transactions. The logic for these rule sets is maintained and operated on the Platform 100 with response messaging to the PSP. When an online merchant wishes to accept via the platform 100 issued PINs, by way of registration forms hosted by the platform 100 the merchant enrols for the service. In doing so they set up specific rules as to how their transactions should be treated. For example, the merchant can decide to add a surcharge automatically to each transaction either as a fixed value or as a percentage of the transaction. Alternatively the merchant can choose to credit a customer account with value in the same manner. The merchant can also configure how they wish their transactions to be handled through a rules-based configurator that allows transactions to enter a pending status until such time as certain thresholds have been met. These thresholds will include the following parameters but are not limited to: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters. Once a threshold has been met the platform 100 will carry out a process whereby each PIN is mapped to a specific PAN (not a requirement where no PAN already exists) or the merchant is issued a master PAN (where one does not already exist) which collates all of the PINs onto one PAN which is then sent for authorisation. Alternatively, the use of a pre-generated master PAN may be mandated by the platform 100 for all PINs. The treatment of each PIN received by the platform 100 from a PSP will depend on the pre- set rule set stored on the platform 100 server applicable to that particular online merchant. Batching PINs together to create a single PAN reduces transaction complexity to the online merchant thus allowing them to efficiently process low value or micro transactions which heretofore has been a significant issue for online merchants where a payment card has been used by the customer.

A merchant can also choose to create a master PAN specific to that merchant such that all PIN transactions are mapped directly to this PAN on a continuous basis. Alternatively, they can choose to have each PIN mapped to a specific individual PAN, or this may be forced.

Once the merchant completes the registration the rules-based logic is stored on the platform 100 awaiting transaction data directly from the merchant via a platform 100 linked PSP.

The following describes, with reference to Fig. 3 onwards the flows for various stages, as illustrative examples.

Retail outlet purchase - Data Flow

Fig. 3 shows the flow of data when a consumer purchases a PIN at a retail outlet. (1) A consumer enters a retail outlet or an online PIN sales portal and requests a PIN for a specific amount and pays the requested value.

(2) The shop clerk processes the request and a PIN request is sent to the platform 100.

(3) The platform 100 processes the request from the retail outlet.

(4) A response containing the PIN details is sent back to the retail outlet.

(5) The POS prints a PIN receipt containing the PIN details for the requested amount and completes the sale.

Activating a PIN

Before a consumer can use their purchased PIN online, they will need to activate the PIN via either of the PIN user interfaces - mobile application and web site.

Activating a PIN - Data Flow

Fig. 4 shows the flow of data when a consumer activates a PIN:

(1) A consumer logs into their previously-registered PIN account via either of the PIN user interfaces and enters the PIN details into the user interface and request activation. Activation of a customer's first PIN can include a registration process.

(2) The activation request is sent to the platform 100, where the PIN is validated and a safe code generated. The PIN format may be changed at this point for added security.

(3) The activation response containing the safe code details is sent back to the PIN user interface.

(4) The consumer is presented with the safe code for use during online shopping. Using a PIN

Once a consumer purchases and activates a PIN, they can use the PIN (in whatever format it is activated) in conjunction with the safe code they received when registering the PIN to purchase goods and/or services with online merchants.

When a consumer uses a PIN to purchase online, there are two possible data flows for authorizing the transaction:

- Approval - this is where the registered merchant's configured threshold has not been reached and the approval is done by the platform 100. Importantly, the PAN is not sent to the scheme network. This avoids unnecessary traffic into the scheme network, and also provides a faster response time.

- Authorization - this scenario is applicable when a merchant's configured threshold has been reached and the transaction is sent for authorization via the normal scheme network, via an acquiring gateway.

Approval - Data Flow

Fig. 5 shows the flow of data when a consumer uses a PIN to purchase online and only approval is required:

(1) A consumer enters their PIN and a safe code during checkout at the online merchant.

(2) The online merchant, who has signed up for PIN processing and has been configured on the platform 100, sends the transaction details to their PSP.

(3) The PSP 202 recognizes that the transaction is using a PIN and forwards the details to platform 100 for approval.

(4) The platform 100 approves and checks the merchant configuration settings and if the merchant's configured threshold has not been met, it approves the PIN (amount, validity), adds the transaction to the merchant's configured transaction threshold and responds with a successful approval message to the PSP. The Platform 100 decrements the PIN balance and records the transaction.

(5) The PSP sends the approval back to the online merchant.

(6) The consumer is presented with an approval message for a proposed transaction. Full Authorization - Data Flow

Fig. 6 shows the flow of data when a consumer uses a PIN to purchase online and full authorization is required:

(1) A consumer enters their PIN and safe code during checkout at the online merchant.

(3) The PSP 202 recognizes that the transaction is using a PIN and forwards the details to the platform 100 for validation. (4) The platform 100 validates and checks the merchant configuration settings and if the merchant's configured threshold has been met (or no threshold has been set and all transactions go for full authorization) the platform 100 sends a response message containing the details of a PAN (newly issued or pre-existing) and any other details required, as well as the accumulated amount for the batch of transactions recorded against the merchant's threshold if batching is in place, back to the PSP 202 for normal acquiring processing.

(5) The PSP sends the transaction to the scheme network for processing.

(6) The scheme network returns the transaction result to the PSP.

(7) The PSP 202 notifies the platform 100.

(8) The platform 100 replies to the PSP 202.

(9) The PSP 202 sends the transaction result back to the online merchant 201.

(10) The consumer device 200 is presented with a successful transaction message. Functional Components

The following briefly summarises each of the functional components required for implementation of the transactions processing methods of the invention.

Platform 100

- PIN generation.

- Safe code generation

- Code distribution (via for example retail outlet, online channels).

- Transaction approval in advance.

PAN routing to PSPs

- Consumer PIN balance and transaction management and recording

- Mapping of PINs to PANs and vice versa.

- Two user interfaces (Web site and mobile application) will be available to consumers, which will allow them to execute the following functions:

• PIN account creation,

· PIN account management,

• PIN code purchase,

• PIN code management.

- Settlement and reconciliation reporting. Merging PINs

PINs with available balances can be merged together in order to create a code with an increased balance for a bigger purchase. The following rules apply:

- One PIN balance is merged with another PIN balance, giving the consumer a higher PIN balance and potentially an extension on expiry when merging PINs.

- The sending PIN must be marked as "used/transferred" which should render the PIN as unusable and this PIN and any corresponding PAN balance are reduced to zero, and the receiving PIN and corresponding PAN are accordingly credited. The following scenarios exist when a consumer wants to merge a PIN with another PIN:

- Merging used PINs.

- Merging unused PINs.

- Merging used and unused PINs. (a) A consumer logs into their PIN account via one of the user interfaces.

(b) The consumer is taken to the home page - which is the list of PINs against their account.

(c) The consumer selects the PINs and chooses "Merge PIN" from the user interface.

(d) The PIN merge request is sent to the Platform 100.

(e) The platform validates the request by checking if there is an available balance and if they are not expired, in order to merge the PINs:

(f) If the merge request is not valid, an error message is sent back to the consumer informing them of same.

(g) If the merge request is valid, the PINs are merged and a single PIN remains with a new balance.

(h) A message confirming the merge has been successful is sent to the consumer. Blocking PINs

If a customer code has been potentially compromised, the customer has the option to block it via the user interfaces. For example, PIN block requests can be carried out on any state of PIN, namely active, inactive, or merged.

(a) A consumer logs into their PIN account via one of the user interfaces.

(b) The consumer is taken to the home page - which is the list of PINs against their PIN account.

(c) The consumer selects the PINs and chooses "Block PIN" from the user interface. (d) The Block PIN request is sent to the platform 100.

(e) The platform 100 validates the request, PINs can only be blocked if they adhere to the following:

i. Is a valid PIN ,

(f) If the block request is not valid, an error message is sent back to the consumer informing them of same,

(g) If the block request is valid:

i. the PIN is marked as "blocked" rendering it no longer usable,

ii. a new PIN is generated with the same balance to replace the blocked PIN .

(h) The details of the new PIN are sent back to the user interface, informing the consumer that the block request was successful.

Transfer PINs

PINs can be used to transfer money instantly between consumers or to bank accounts.

(a) A consumer logs into their PIN account via one of the user interfaces.

(b) The consumer is taken to the home page - which is the list of PIN codes against their PIN account.

(c) The consumer selects the PIN and chooses "Send PIN" from the user interface.

(d) The consumer provides the mobile phone number of the recipient of the PIN, either by entering it or selecting the mobile number from a favourites or contacts list.

(e) The request is sent to the platform 100 for processing.

(f) The platform validates the request, in which the following must be valid:

i. PIN must have a balance,

ii. The recipient must have a PIN account,

iii. Both the sender and the receiving PIN account holders must be within their daily/yearly limits.

(g) If the request is not valid, an error message is sent back to the user interface informing them of same.

(h) If the request is valid:

i. The selected PIN is removed from the sender PIN account,

ii. The selected PIN is saved against the receivers' PIN account.

(i) A message is sent back to the user interface informing the consumer that the request was successful.

(j) An SMS Message is sent to the receivers' mobile number informing them that they have received a PIN. The above provides a mechanism for transfer of financial value in real time between parties without need to involve the scheme network. It will be appreciated that the enablement network of the invention allows a customer to purchase a PIN either online or in a convenience store or any other physical outlet. Also, a merchant can accept this PIN by installing a piece of code presented as an API or a library of APIs such that they create a secure connection to the platform 100, or by registering for acceptance of PINs with their PSP, and in real time have the PIN translated into, or mapped to a pre-existing, Payment Scheme (MasterCard™/Visa™) Primary Account Number (PAN). It can also batch a number of PINs and match them against a master PAN for individual merchants for processing at a later time. Another advantage is that the PAN can be transmitted into the normal authorisation and settlement processes, and that the customer can view electronically their full transaction history for each PIN as well as merge, redeem and transfer value to other customers.

It will also be appreciated that the enablement network integrates core components of payment issuing and acquiring to offer an online payments system that does not require the online merchant to significantly change their current technical or settlement processes. The merchant system can be loaded with the required software at the PSP, or it can be deployed through installing code which creates a secure connection between the online merchant's payment acceptance system and the platform 100 thus allowing the online merchant to immediately accept cash and bank payments via the platform 100 issued PINs.

Advantageously, the customer will see any remaining residual balance or to redeem unused funds in their account. This account functionality may be accessed by Application, Internet, IVR, SMS or any other means of electronic communication. This functionality includes:

- Checking a PIN balance and transaction history

- Redeeming unused funds from a PIN to a bank account

- Merging the value of one PIN to another

- Transferring the value of a PIN to another customer by means of drag and drop

- Identifying a store where a PIN can be purchased

- Identifying purchase source for a PIN

- Purchasing a PIN by debit or credit card The customer also has the option of creating their own self-generated customer code other than one having the format of a PIN. It may be a master PIN made up of for example of personal details such as date of birth, and username and have that as a single payment ID that may match back to any single PIN or combination of PINs that exist in their account. The customer may also set up an automated bank account transfer system whereby the enablement network will allow the customer to enter an identifier on an online merchant's website and in the background the enablement network creates a matching PAN funded from a bank account that is authorised and settled in the same manner as normal payment cards.

The invention is not limited to the embodiments described but may be varied in construction and detail. For example, an alternative process for purchasing a customer code includes a user first creating an account either online or via an application. The user can then enter a store and lodge funds to this account by inputting their mobile phone number at the point-of-sale terminal in store or some other electronic data capture device. The system will then automatically allocate a PIN number to that account which the customer can access electronically via their registered account. Additionally, single use PINs can be issued.

Alternatively, a unique merchant PAN can be generated for the processing of payments. Upon registration a PAN is generated for a specific merchant on the processor 110. When a customer makes a payment with a PIN at the merchant, the PIN is sent via the PSP to the platform 100 as previously described for validation and the PIN is mapped to the pre-generated PAN. The platform 100 confirms the payment and decrements the PIN balance and credits the pre- generated PAN accordingly. The PAN is returned to the PSP for payment processing as previously described. If the merchant has specified that full authorization is to be batched, multiple customer PINs can be mapped to the pre-generated PAN before it is sent to the PSP for batch authorization. In this manner the costs of the system is reduced by eliminating the need to generate an individual PAN for each PIN.

If a customer makes purchases at multiple merchants the customer PIN will be mapped to multiple pre-generated PANs. Balance and transaction management is operated by the Platform 100.

Claims

1. A transaction processing enablement network (100, 110) comprising digital processors and communication circuits adapted to:

receive from a merchant system (201) or a payment service provider PSP system (202) a customer code which has been presented by a customer for a transaction, and also transaction data,

provide a corresponding PAN for the customer code, and send to the merchant system or PSP system the PAN and transaction data sufficient for a scheme network transaction, and to

subsequently receive from the scheme network (203) an authorisation request, process said request, and respond to the scheme network.

2. A transaction processing enablement network as claimed in claim 1, wherein the enablement network (100, 110) is adapted to, after authorisation, map a transaction balance of the PAN back to the customer code and vice versa.

3. A transaction processing enablement network as claimed in claims 1 or 2, wherein the enablement network (100, 110) comprises and is adapted to maintain a database of transaction logs for both the customer and the merchant.

4. A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) is adapted to generate and handle multiple PANs for a single customer code or multiple customer codes for a single PAN.

5. A transaction processing enablement network as claimed in any preceding claim, wherein the network (100, 110) is adapted to decrement after each transaction a customer code financial value.

6. A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) comprises:

a first logical group (100) of 1 to N servers for interfacing with the merchant and/or PSP system, and

a second logical group (110) of 1 to M servers for generating the PANs and interfacing with the scheme network.

7. A transaction processing enablement network as claimed in claim 6, wherein the second group (110) interfaces with the first group (100), and the second group is isolated from merchant (201) and PSP systems (202).

A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) is adapted to generate a master PAN linked to one or more related customer codes, and to use the master PAN to submit to the scheme network a batch of transactions for a single transaction process through the scheme network, or submit the master PAN to the scheme network for each transaction where batching is not in place.

A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) is adapted to manage issuance of said customer codes.

A transaction processing enablement network as claimed in any preceding claim, wherein the customer code is associated with a fixed maximum value.

A transaction processing enablement network as claimed in claims 9 or 10, wherein the enablement network is adapted to verify a received customer code upon receipt.

A transaction processing enablement network as claimed in any preceding claim, wherein said network comprises a first platform adapted to connect directly to a PSP system to map customer codes to PANs generated by a second platform of said network and to send PANs through the PSP for authorisation and settlement by the scheme.

A transaction processing enablement network as claimed in claim 12, wherein said first platform is adapted to have a secure connection to a PSP system (202), to point of sale terminals (201), or to servers linked to such terminals, and to the second platform and provide and maintain customer and merchant code and transaction data.

14. A transaction processing enablement network as claimed in claims 12 or 13, wherein said second platform is adapted to maintain connectivity with an Application Protocol Interface to a gateway (203) of a scheme network in order to settle payment card transactions.

A transaction processing enablement network as claimed in claim 14, wherein the second platform is adapted to create and maintain said PANs, and the first platform is connected directly to the second platform through a published set of Application Protocol Interfaces.

A transaction processing enablement network as claimed in any preceding claim, wherein the network is adapted to perform customer registration in which customer data is validated by sending a short code that the customer then needs to input back into the network, in order to validate themselves for security and identification.

A transaction processing enablement network as claimed in any preceding claim, wherein said network (100, 110) is adapted to provide a password-protected mobile application or website to allow customer entry of their customer code, and to return a safe code that acts as an additional security validation such that both the customer code and the safe code are required to be inputted by a customer to allow the transaction to proceed.

A transaction processing enablement network as claimed in any preceding claim, wherein said network is adapted to return to a merchant system (201) or customer device (200) a new format of the customer code for additional security.

A transaction processing enablement network as claimed in any preceding claim, wherein said enablement network (100, 110) is adapted to treat each received customer code according to a pre-set rule set applicable to the particular merchant.

A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) is adapted to perform a pre-transaction approval without accessing a scheme network.

A transaction processing enablement network as claimed in claim 20, wherein the enablement network (100, 110) is adapted to perform said approval using a financial balance associated with a customer and stored internally within the enablement network.

22. A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network (100, 110) is adapted to merge customer codes.

A transaction processing enablement network as claimed in claim 22, wherein the enablement network (100, 110) is adapted to perform the following steps to merge customer codes:

the receiving code and corresponding PAN are accordingly credited.

A transaction processing enablement network as claimed in claims 22 or 23, wherein the enablement network is adapted to generate a safe code, to use both the safe code and a customer code for interfacing with an external system for added security, and to merge combinations of safe codes and customer codes.

A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network is adapted to create a master PAN specific to a merchant and to map a plurality of customer codes back to said master PAN.

A transaction processing enablement network as claimed in any of claims 6 to 25, wherein the enablement network first platform (100) is adapted to integrate to a Payment Service Provider (202) via specific Application Protocol Interfaces that include creation of a secure connection, building of forms, interchange of specific messaging protocols and protection of stored data, and in which the integration includes merchant rules that apply to merchant transactions and logic for these rule sets is maintained and operated on the first platform (100) with response messaging to the PSP.

27. A transaction processing enablement network as claimed in claim 26, wherein the enablement network is adapted to execute a rules configurator to allow a merchant system (201) to configure how they wish their transactions to be handled, including rules that allow transactions to enter a pending status until such time as certain thresholds have been met.

A transaction processing enablement network as claimed in claim 27, wherein the thresholds include the following parameters: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters.

A transaction processing enablement network as claimed in any preceding claim, wherein the enablement network is adapted to manage a unique merchant PAN for use with multiple customer codes and transactions.

A transaction processing enablement network as claimed in claim 29, wherein the enablement network is adapted to return the PAN to a PSP for payment processing, and if the merchant has specified that full authorization is to be batched, map multiple customer codes to the pre-generated PAN before it is sent to the PSP for batch authorization.

A transaction processing enablement network as claimed in claim 30, wherein the enablement network (100, 110) is adapted to, if a customer makes purchases at multiple merchants, map the customer code to multiple pre-generated PANs.

A transaction processing enablement network as claimed in claim 31, where the enablement network (100, 110) is adapted to, at a point of transaction, debit a surcharge from a customer code balance in excess of the transaction amount, or a loyalty bonus credited to the customer code, as per the merchant's pre-set settings.

A transaction processing method performed by an enablement network (100, 110) comprising digital processors and communication circuits, a merchant system, a PSP system (202), and a gateway (203) to a scheme network, the method comprising the steps of:

the enablement network (100, 110) receiving from the merchant system (201) or the PSP system (202) a customer code which has been presented by a customer (200) for a transaction, and also transaction data,

the enablement network providing a corresponding PAN for the customer code, and sending to the merchant system (201) or the PSP system (202) the PAN and transaction data sufficient for the scheme network transaction, and the enablement network (100, 110) subsequently receiving from the scheme network (203) an authorisation request, processing said request, and responding to the scheme network.

A method as claimed in claim 33, wherein the enablement network, after authorisation, maps a transaction balance of the PAN back to the customer code or vice versa.

35. A method as claimed in claims 33 or 34, wherein the enablement network (100, 110) comprises and maintains a database of transaction logs for both the customer and the merchant.

36. A method as claimed in any of claims 33 to 35, wherein the enablement network generates and handles multiple PANs for a single customer code or multiple customer codes for a single PAN.

37. A method as claimed in any of claims 33 to 36, wherein the enablement network decrements after each transaction a customer code financial value.

38. A method as claimed in any of claims 33 to 37, wherein the enablement network generates a master PAN linked to one or more related customer codes, and uses the master PAN to submit to the scheme network a batch of transactions for a single transaction process through the scheme network, or submit the master PAN to the scheme network for each transaction where batching is not in place.

39. A method as claimed in any of claims 33 to 38, wherein the enablement network (100, 110) manages issuance of said customer codes.

40. A method as claimed in any of claims 33 to 39, wherein the customer code is associated with a fixed maximum value.

41. A method as claimed in any of claims 33 to 40, wherein the enablement network (100, 110) verifies a received customer code upon receipt.

42. A method as claimed in any of claims 33 to 41, wherein the enablement network performs customer registration in which customer data is validated by sending a short code that the customer then needs to input back into the network, in order to validate themselves for security and identification.

43. A method as claimed in any of claims 33 to 42, wherein the enablement network provides a password-protected mobile application or website to allow customer entry of their customer code, and returns a safe code that acts as an additional security validation such that both the customer code and the safe code are required to be inputted by a customer to allow the transaction to proceed.

44. A method as claimed in any of claims 33 to 43, wherein the enablement network returns to the merchant system (201) or customer device (200) a new format of the customer code for additional security.

45. A method as claimed in any of claims 33 to 44, wherein said enablement network treats each received customer code according to a pre- set rule set applicable to the particular merchant.

46. A method as claimed in any of claims 33 to 45, wherein the enablement network performs a pre-transaction approval without accessing a scheme network.

47. A method as claimed in claim 46, wherein the enablement network performs said approval using a financial balance associated with a customer and stored internally within the enablement network.

48. A method as claimed in any of claims 33 to 47, wherein the enablement network merges customer codes.

49. A method as claimed in claim 48, wherein the enablement network performs the following steps to merge customer codes: a balance for a customer code is merged with another balance, giving the consumer consolidated funds and potentially an extension on expiry when merging codes,

the receiving code and corresponding PAN are accordingly credited.

50. A method as claimed in claims 48 or 49, wherein the enablement network generates a safe code, uses both the safe code and a customer code for interfacing with an external system for added security, and merges combinations of safe codes and customer codes.

51. A method as claimed in any of claims 33 to 50, wherein the enablement network (100, 110) creates a master PAN specific to a merchant and maps a plurality of customer codes back to said master PAN.

52. A method as claimed in any of claims 33 to 51, wherein the enablement network (100, 110) executes a rules configurator to allow a merchant system to configure how they wish their transactions to be handled, including rules that allow transactions to enter a pending status until such time as certain thresholds have been met.

53. A method as claimed in claim 52, wherein the thresholds include the following parameters: type of customer, value of transaction, volume of transaction, time periods or combinations of the parameters.

54. A method as claimed in any of claims 33 to 53, wherein the enablement network manages a unique merchant PAN for use with multiple customer codes and transactions.

55. A method as claimed in claim 54, wherein the enablement network returns the PAN to the PSP for payment processing, and if the merchant has specified that full authorization is to be batched, multiple customer codes are mapped to the pre-generated PAN before it is sent to the PSP for batch authorization.

56. A method as claimed in claim 55, wherein, if a customer makes purchases at multiple merchants, the enablement network (100, 110) maps the customer code to multiple pre- generated PANs.

57. A method as claimed in claim 56, where the enablement network, at a point of transaction, debits a surcharge from a customer code balance in excess of the transaction amount, or a loyalty bonus credited to the customer code, as per the merchant's pre-set settings.

58. A method as claimed in any of claims 33 to 57, wherein the enablement network manages transfer of money between two persons by changing association of customer codes to persons.

59. A method as claimed in claim 58, wherein the enablement network manages said transfer by: receiving from a sender with a customer code a request to send the customer code to a recipient, and unique data identifying the recipient, validating the request, in which the following must be valid:

an account of the sender has a financial balance,

the recipient has an account registered with the enablement network, the sender and the recipient accounts are within transaction amount limits for time periods,

sending a message to the sender to indicate that the request was successful, and sending a message to the recipient to inform them that they have received a customer code.

60. A computer readable medium comprising software code adapted to perform the steps of a method of any of claims 33 to 59 when executing on a digital processor.