GB2506881A

GB2506881A - System and method for enrolment of payment transaction services

Info

Publication number: GB2506881A
Application number: GB1218188.9A
Authority: GB
Inventors: James Gardiner; Colin Mcskeane
Original assignee: Barclays Bank PLC
Current assignee: Barclays Bank PLC
Priority date: 2012-10-10
Filing date: 2012-10-10
Publication date: 2014-04-16
Also published as: US20140101048A1; GB201218188D0; EP2907097A1; WO2014057272A1

Abstract

In an electronic payment transaction, a mobile device captures customer card details using an integrated camera. A user is registered to initiate the payment transaction using a mobile payment application on the mobile device. The registration process involves retrieving customer data associated with the captured customer card details to pre-populate an enrolment form. The user authentication is provided by verifying input authentication data or by an existing mobile service application.

Description

System and Method for Enrolment of Payment Transaction Services

Field of the Invention

[0001] This invention relates to a transaction payment system, and more particularly to a system and method for providing enhanced enrolment of card payment transaction services.

Background of the Invention

[0002] Payment transaction systems that use a mobile data terminal to handle Point of Sale' (PUS) credit/debit card transactions for a merchant are known. Typically, the merchant's data terminal can be a mobile smartphone, tablet computer or portable computing device with cellular data communication capabilities, such as GPRS, EDGE or 3G. and capable of running a payment application. The payment application preferably provides accounting functions for the merchant, such as calculating a total bill, printing receipts, providing summaries of transactions etc. and can communicate electronically with a transaction processing back-end server to process and settle the transactions.

[0003] A payment card reader may be provided as a peripheral device in communication with the data terminal. Alternatively, the merchant's data terminal may capture the customer's card details using a scanner or camera, for example as disclosed in US-A-2010/0008535 (Jumio). This technique does not require a card reader, so may be implemented on a standard smartphone with an integrated camera, but is inherently less secure than the commonly used Chip and PIN' card reader.

[0004] As such card payment systems become more prevalent, there is a need for improved systems and techniques to provide more efficient tools and processes for enrolment of available services, without sacrificing security against fraudulent use.

Statements of the Invention

[0005] Aspects of the present invention are set out in the accompanying claims.

[0006] According to one aspect of the present invention, there is provided a method and system for authenticating a payment transaction between a merchant and a customer in an electronic payment system, in which a mobile device captures card details for the transaction without the need for a dedicated card reader. Preferably, a camera integrated with the mobile device is used to capture an image of the card, from which card details are extracted by known Optical Character Recognition (OCR) techniques.

[0007] A user is registered to initiate the payment transaction using a mobile payment application on the mobile device. The registration process involves retrieving customer data associated with the captured customer card details to pre-populate an enrolment form. Preferably, user authentication is provided by verifying input authentication data.

[0008] According to another aspect, there is provided a method and system for processing enrolment of a user for a mobile payment transaction service in an electronic banking system, the user being pre-registered for another service in the electronic banking system. A mobile device captures card details for the enrolment IS process and the transaction process without the need for a dedicated card reader, and user authentication is provided by an existing mobile service application on the mobile device.

[0009] In a further aspect of the present invention there is provided a mobile device, an authentication system, and associated computer programs arranged to carry out at least one of the above methods.

Brief Description of the Drawings

[0010] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

[0011] Figure 1 is a block diagram showing the main components of a payment processing system according to an embodiment of the invention.

[0012] Figure 2, which comprises Figures 2A and 2B, is a flow diagram illustrating the main processing steps performed by the system of Figure 1 according to an embodiment.

[0013] Figure 3 is a flow diagram illustrating the sub processing steps performed by the system of Figure 1 to process a payment transaction according to an exemplary embodiment.

[0014] Figure 4 is a block diagram showing the main components of a payment processing system according to an alternative embodiment of the invention.

[0015] Figure 5 is a diagram of an example of a computer system on which one or more of the functions of the embodiment may be implemented.

Detailed Description of Embodiments of the Invention

Card Payment Background

[0016] Card payments are a way of paying for goods and services without cash changing hands; the presentation of the card details and appropriate card holder authentication guarantee the merchant payment. A conventional card payment system is made up of a number of components: card holder, merchant, acquirer, scheme and issuer.

[0017] In the normal process the card holder presents his card (or payment token) to the merchant in order to pay for goods or services rendered; this transaction may take place over any one of a number of channels (in store or via the Internet, for example).

The merchant, through his acquirer, is set up to accept different card types by scheme (Vi5aRTM, MasterCardRTM, AmexRTM, credit, debit, for example). When a card is presented, the card holder is authenticated (by Personal Identification Number, PIN, passcode, or Card Verification Value, CV2, for example), subject to channel and merchant capability, and the transaction is submitted to the merchant's acquirer for authorisation. Authorisation and authentication of the merchant and/or card holder may instead or additionally be handled through a trusted third party authentication system that is known to the merchant acquirer.

[0018] Once the transaction is received, the acquirer routes the authorisation transaction, in real time, to the relevant scheme based upon card type. The scheme provides isolation between acquirers and issuers for routing of authorisations, settlements and funds movement. The acquirer doesn't need to know who the issuer is, just which scheme to route it to which is determined by Bank Identification Number (BIN).

[0019] The issuer authorises the transaction based upon the card holder's balance and other risk/fraud criteria and returns an authorised message and authorisation code to the scheme, which routes it back to the acquirer who sent it to the merchant. The merchant then confirms the sale, which posts a settlement transaction to the acquirer; this is a mandate to make the payment and move funds. The settlement transaction is routed between acquirers and issuers via the scheme.

Technical Architecture [0020] Referring to Figure 1, a payment transaction system 1 according to an embodiment of the invention comprises a user system 3 for initiating payment transactions, such as credit/debit card transactions, through a mobile payment application 7a running on a mobile device 7. In a typical payment transaction process, the mobile payment application Ja can receive data identifying goods and/or services associated with the payment transaction, apply discounts or vouchers, determine the total amount due for payment, and initiate authentication of a payment token 11 presented by the customer. The mobile payment application 7a must obtain details of the payment token 11 before the payment transaction can be settled and completed.

[0021] In the present embodiment, the payment token 11 is a credit or debit card of conventional type, carrying at least a card number, expiry date and cardholder name on the front side and a card security code on the reverse side. Optionally, the card may include additional information identifying an associated bank account, such as an account number and branch sort code.

[0022] The mobile device 7 can be a mobile smartphone, tablet computer or portable computing device, or the like, and communicates with a transaction processing module via a data network 9. The mobile payment application 7a can be secured by means of a passcode and information associated with a payment transaction can be provided via the secured mobile payment application 7a running on the mobile device 7. Electronic data communication by the mobile payment application 7a may be encrypted.

[0023] The data network 9 may be any suitable data communication network such as a wireless network, a local-or wide-area network including a corporate intranet or the Internet, using for example the TCP/IP protocol, or a cellular communication network such as GPRS, EDGE or 3G, for example. Such communication protocols are of a type that are known perse in data networks and need not be described further.

[0024] Components of the user system 3 are also in communication with a merchant acquirer 2a, payment scheme 2b and card issuer 2c components over the data network 9, which are typically provided for authorizing and settling card payment transactions as described in the section above, and need not be described further.

[0025] In this embodiment, additional authentication is handled through an authentication system S hosted by a trusted third party that is known to the merchant acquirer 2a. Alternatively, the authentication system 5 may be provided as a component of the merchant acquirer 2a. As will be described below, this authentication system 5 includes a registration module Sa for processing registration IS of the user to initiate payment transactions using the mobile payment application 7a on the mobile device 7, and an authentication module Sb for providing an authentication security check, for example prior to registration processing and/or authorisation processing of a payment transaction. Additionally, the authentication system 5 can store user information associated with registered card holders of the system 1, in a customer database Sc. Alternatively, the authentication system 5 can be adapted to retrieve the user information from the card issuer 2c.

[0026] The mobile device 7 includes a digital camera 7b for scanning or imaging the payment token 11 so as to capture the card details at least from the front side of the card. The digital camera 7b is controlled by the payment transaction app 7a to capture a digital still or moving image of the front side of the card. The payment transaction app 7a obtains the card details from the digital image using an Optical Character Recognition (OCR) module 7c.

[0027] The mobile device 7 also includes an electronic enrolment form 7d for receiving information from the user during the registration process. As will be described below, the registration module Sa retrieves customer data associated with the captured card details from the customer database 5c, and the retrieved customer data is used by the mobile payment application la to pre-populate respective input data fields in the enrolment form 7d. By pre-populating the enrolment form 7d in this way, the registration process is more efficient and security of the payment system is not compromised.

Mobile Payment Application Registration Process [0028] An embodiment of a process of registering a user for the mobile payment application 7a will now be described with reference to Figure 2, to illustrate the technical advantage of the payment transaction system embodiment described above.

In this embodiment, the user can be a merchant or a customer in the payment transaction system.

[0029] The registration process begins at step S2-1 where the mobile payment application 7a on the mobile device 7 receives user input to initiate a registration process. The registration process can be initiated the first time that the user launches the mobile payment application 7a, for example after installation of the application on the mobile device 7.

[0030] At step S2-3, the mobile payment application 7a captures a digital image of the front side of a card presented by the user and obtains the card details using an OCR process on the digital image, as described above. This conveniently avoids the user having to enter the card number and other details manually.

[0031] At step S2-5, the mobile payment application 7a prompts the user to input authentication data. It will be appreciated that user authentication can take one or more of any number of known forms. As one example, the user can input a unique, one-time passcode generated by an external card reader and authentication device (not illustrated). As another example, the mobile device 7 can include a one-time passcode generator module (not illustrated) to generate and pass a unique one-time passcode to the mobile payment application 7a, or the mobile payment application 7a itself can include such a one-time passcode generator module. As yet another example, the mobile payment application 7a displays a data entry screen to the user, prompting the user to enter their card security code, such as the CV2 code. The mobile payment application 7a may request input of alternative or additional authentication information, such as the cardholder's postal (zip) code, details of a recent transaction, passwords or passcodes from other related servicing accounts, answer to a pre-registered security questions such as the cardholder's favourite colour or make of first car, etc. [0032] At step S2-7, the mobile payment application 7a transmits the input authentication data together with the captured card details, to the authentication system 5 where the data is received, at step 52-9. At step 52-11, the authentication module 5b in the authentication system S uses the card details to access a corresponding cardholder record in the customer database Sc and authenticates the authentication data against the cardholder record, to verify that the user is the owner of the captured card details. After the user is authenticated, the authentication system S retrieves user data from the cardholder record, at step 52-13. The user data can include one or more of the card holder's name, address, contact details, bank IS account number, business or trading name, trading address, etc. that would have been captured by a previous registration and authentication process, for example when the user applied for the payment token. The user data may be encoded using a standard format, such as XML that identifies a respective element type associated with each value in the user data.

[0033] At step 52-15, the authentication system S transmits the retrieved user data to the mobile payment application 7a where the data is received, at step 52-17. At step 52-19, the mobile payment application 7a uses the user data to pre-populate as many input data fields as possible in the enrolment form 7d. For example, the mobile payment application 7a may match element types in the received user data to input data field types in the enrolment form 7d to determine the fields that can be populated with associated values in the received user data.

[0034] After the mobile payment application 7a pre-populates the enrolment form 7d with the received user data, the user may be prompted to review all pre-populated data. At step 52-21, the mobile payment application 7a receives user input to edit or complete any additional required fields where the associated values were not available

S

from the user data. For example, in the case of a merchant account, the additional required details may include business turnover, expected card turnover, average transaction value, whether the merchant takes payment for a deferred delivery or takes deposits, etc. The system may be configured to assign default values for some or all of these fields, such as expected card turnover and average transaction value, and the user may be able to edit the pre-populated default values.

[0035] At step 52-23, the mobile payment application 7a transmits the completed enrolment form data to the registration module 5a of the authentication system 5 where the data is received, at step 52-25. At step 52-27, the authentication system 5 verifies the enrolment form data against the corresponding cardholder record in the customer database Sc before registering the user as an authorised user to initiate payment transactions using the mobile payment application 7a on the mobile device 7.

It will be appreciated that the registration decisioning process may involve additional processing steps before user registration is approved or declined, such as carrying out IS a series of additional checks, including credit bureau checks and payment scheme checks (e.g. Visa/Mastercard) as are known per Se. At step S2-29, the authentication system S transmits data indicative of authorisation to the mobile payment application 7a where the data is received, at step 52-31. The mobile payment application 7a is thereby enabled for the approved and registered user to initiate and process a payment transaction, at step 52-33. In this way, the mobile device 7 is effectively initiated after receiving the approved decision, such that all mobile payment functionality via the mobile payment application 7a becomes unlocked and the user is able to process card payments and use all additional features provided by the mobile payment application 7a.

[0036] Optionally, if the authentication system S fails to authenticate the authentication data and/or verify the enrolment form data, or if the decisioning process otherwise fails and the user is not approved for registration, the authentication system 5 may send an alert message to an address registered in the cardholder record to inform the user of the decision. The address may be a mobile number for sending a text or multimedia message, an email address, or a postal address.

Payment Authentication Process [0037] An exemplary embodiment of the process of payment authentication at step 52-33 will now be described in further detail with reference to Figure 3, to illustrate the technical synergy between the registration process and the payment authentication process that both involve the captured card details.

[0038] The payment authentication process begins at step S3-1 where details for a new payment transaction are obtained by the mobile payment application 7a running on the mobile device 7. The transaction details typically include a payment amount to be transferred and data identifying the transaction, such as the time and date of the transaction and a description of the associated goods or services. The mobile payment application 7a may scan codes (such as 1D barcodes or 2D QR codes) associated with the goods or services to obtain details of the transaction.

[0039] At step 53-3, the mobile payment application 7a captures a digital image of the front side of a card presented by the user and obtains the card details using an OCR process on the digital image, as described above. Again, this avoids the user having to enter the card number and other details manually, whilst maintaining a degree of security as the card must be present for this step of the payment transaction process.

[0040] At step S3-5, the mobile payment application 7a displays a data entry screen to the user, prompting the user to enter their card security code, such as the CV2 code.

The mobile payment application 7a may request input of alternative or additional authentication information, such as the cardholder's postal (zip) code for comparison with the cardholder's registered billing address.

[0041] At step 53-], the mobile payment application 7a transmits the received authentication data together with the captured card details, to the authentication system 5 where the data is received by the authentication module Sb, at step 53-9. At step 53-11, the authentication system 5 uses the card details to access a corresponding cardholder record from the customer database Sc and authenticates the authentication data against the cardholder record. It will be appreciate that the cardholder record may be typically held by the card issuer 2c, so the authentication system S may delegate the authentication step to the card issuer 2c, via the payment scheme 2b, and receive an authentication response from the card issuer 2c.

Alternatively, the merchant application 7a may send the authentication data to the merchant acquirer 2a for authentication.

[0042] At step S3-13, the authentication system 5 sends an authentication result to the mobile payment application 7a, dependent on the authentication of the authentication data. At step S3-15, the mobile payment application 7a may complete or cancel the transaction, depending on the received authentication result.

[0043] Optionally, if the authentication system 5 fails to authenticate the authentication data during the payment authentication process, it may send an alert message to an address registered in the cardholder record, as described above.

[0044] In this way, acquirers and merchants in the payment transaction system are provided with a more efficient registration and payment transaction processing system IS whilst maintaining security and non-repudiation of payment transactions.

Alternative Embodiment [0045] A further embodiment will now be described using corresponding reference numerals to those of preceding figures where appropriate for corresponding elements.

Referring to Figure 4, a payment transaction system 101 according to an alternative embodiment of the invention comprises a user system 3 for initiating payment transactions, such as credit/debit card transactions, through a mobile payment application 7a running on a mobile device 7. In this embodiment, additional authentication is handled through an authentication system S hosted by a trusted financial institution 8 that is known to the merchant acquirer 2a.

[0046] In this embodiment, the mobile device 7 includes an additional mobile banking application 10 that the user has previously installed and registered, prior to the registration process for the mobile payment application 7a. The existing mobile banking application 10 provides mobile services to the user, who has already registered with the associated mobile banking system 8a of the financial institution 8 after authentication by the authentication system S. The mobile services provided by the mobile banking application 10 can be any form of existing service, such as transferring of funds between registered mobile device users, accessing banking account details, mobile banking, credit card account servicing, etc. [0047] In this embodiment, the registration process is initiated by receiving a user request from within the existing mobile banking application 10 in order to register for the mobile payment application 7a. The existing mobile banking application 10 requires secure log in by the user before the user can initiate the request, for example by means of a passcode. Therefore, the user is already authenticated with the financial institution at the time of submitting the request, and the authentication steps 52-5 and 52-11 described above are not performed by the system 101 in this alternative embodiment. Instead, the card details are captured and processed by the OCR module 7c at step 52-3, transmitted to the registration module 5a at step 52-7, received at step 52-9, and processed by the authentication system S as described from step 52-13 of the embodiment above.

IS [0048] As a further modification, the embodiments described above can be combined whereby the registration process is initiated from the mobile payment application 7a but authentication of the user is verified by user confirming secure log in to the existing mobile banking application 10. In this modified embodiment, the user can be prompted to input unique user identification data, such as a mobile phone number and the mobile payment application 7a can create a link to the mobile banking application 10.

[0049] In these ways, additional efficiencies are gained by the registration and payment transaction processing system.

Further Alternative Embodiments [0050] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

[0051] The passcodes described above may take any respective form, and may be composed of numeric or alphabetic symbols, non-alphanumeric symbols, or a combination of such symbols.

[0052] The division of operations between the mobile payment application 7a and the authentication system S may differ from that described in the embodiment above. For example, the digital image of the card may be sent to the authentication system 5 for OCR processing. In this case, less processing is required by the mobile payment application 7a, at the expense of greater bandwidth requirements between the mobile payment application 7a and the authentication system Sa.

[0053] Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.

Computer Systems [0054] The entities described herein, such as the mobile device 7 or authentication system 5, may be implemented by computer systems such as computer system 1000 as shown in Figure 5. Embodiments of the present invention may be implemented as programmable code for execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0055] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general-purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network).

Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0056] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit 1018 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 618 includes a computer usable storage medium having stored therein computer software and/or data.

[0057] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a program cartridge and cartridge interface (such as that previously found in video game devices), a removable memory chip (such as an [PROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces 1020 which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

IS [0058] Computer system 1000 may also include a communication interface 1024.

Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels.

[0059] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[0060] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[0061] Alternative embodiments may be implemented as control logic in hardware, IS firmware, or software or any combination thereof.

Claims

CLAIMS: 1. A computer-implemented method of authenticating a payment transaction between a merchant and a customer in an electronic payment system, comprising: a. capturing payment token data from a digital image of a payment token presented by the customer; b. retrieving customer data associated with the payment token data to populate at least a portion of an enrolment form for registering the customer to initiate the payment transaction using a payment application on the customer device; and c. authenticating the payment transaction based on the payment token data.
2. The method of claim 1, wherein the customer device comprises a mobile device.
3. The method of claim 1 or 2, further comprising receiving input of authentication data by the customer and authenticating the authentication data before enabling the customer to initiate the payment transaction using the payment application.
4. The method of claim 3, wherein the authentication data is authenticated against a customer record in a database.
5. A computer-implemented method of processing enrolment of a user for a mobile payment transaction service in an electronic banking system, the user being registered for another service in the electronic banking system, the method comprising: a. initiating an enrolment request for the mobile payment transaction service from an existing mobile service application at a mobile device; b. capturing payment token data from a digital image of a payment token presented by the user; and c. retrieving user data associated with the payment token data to populate at least a portion of an enrolment form for registering the user to initiate the payment transaction using a mobile payment application on the mobile device; wherein authentication of the user is provided by the existing mobile service app Ii cation.
6. The method of claim 5, wherein the user securely logs in to the existing mobile service application.
7. The method of any one of the preceding claims, wherein the digital image is obtained using a camera integrated with the user device.
8. The method of any one of the preceding claims, wherein the payment token comprises a bank card.
9. The method of claim 8, wherein the payment token data comprises an account number displayed on the payment token.
10. The method of any one of the preceding claims, wherein the enrolment form comprises a plurality of input data fields each associated with a respective element type, and wherein data fields of the enrolment form are populated with user data values of a matching element type.
11. The method of claim 10, further comprising receiving user input for additional required input data fields that are not populated with user data values.
12. A system comprising means for performing the method of any one of the preceding claims.
13. A storage medium comprising machine readable instructions stored thereon for causing a computer system to perform a method in accordance with any one of claims ito 12.
14. A method substantially as herein described with reference to the accompanying drawings.
15. A system substantially as herein described with reference to the accompanying drawings.amendments to the claims have been filed as follows 1. A computer-implemented method of authenticating a payment transaction between a merchant and a customer in an electronic payment system, comprising: a. storing, by an authentication system, customer data associated with a registered customer of the system, the customer data including details identifying the customer and an associated payment card; b. initiating, by a payment application on a mobile device, a registration process using a stored electronic enrolment form to authorise the customer to initiate a payment transaction using the payment application on the mobile device, capturing payment card identification data from a digital image of a payment card and transmitting the captured payment (\J card identification data to the authentication system; r c. retrieving, by the authentication system, customer data associated with o 15 the received captured payment card identification data and transmitting the retrieved customer data to the payment application on the mobile device; d. processing, by the payment application on the mobile device, the received retrieved customer data to populate at least a portion of the electronic enrolment form and transmitting the populated electronic enrolment form data to the authentication system; e. processing, by the authentication system, the received electronic enrolment form data and registering the user as an authorised user to initiate a payment transaction using the payment application on the mobile device; and f. initiating, by the payment application on the mobile device, a payment transaction process, capturing payment card identification data from a digital image of a payment card and transmitting the captured payment card identification data to the authentication system; g. retrieving, by the authentication system, customer data associated with the received captured payment card identification data and authenticating the payment transaction for the registered customer based on the retrieved customer data.2. The method of claim 1, further comprising receiving input of authentication data by the customer and authenticating the authentication data before enabling the customer to initiate the payment transaction using the payment application.3. The method of claim 2, wherein the authentication data is authenticated against a customer record in a database.4. The method of claim 1, wherein the customer securely logs in to the payment application on the mobile device. r5. The method of any one of the preceding claims, wherein the payment token data 0 comprises an account number displayed on the payment card.6. The method of any one of the preceding claims, wherein the enrolment form comprises a plurality of input data fields each associated with a respective element type, and wherein data fields of the enrolment form are populated with user data values of a matching element type.7. The method of claim 6, further comprising receiving user input for additional required input data fields that are not populated with user data values.8. A system comprising means configured to perform the method of any one of the preceding claims.9. A storage medium comprising machine readable instructions stored thereon for causing a computer system to perform a method in accordance with any one of claims ito 8.10. A method substantially as herein described with reference to the accompanying drawings.11. A system substantially as herein described with reference to the accompanying drawings. (4 r (4