AU2021101886A4 - Electronic payments platform system and method - Google Patents

Abstract

An electronic payments platform operates by hosting a payments server (100) accessible via the internet (200) and storing a record of payment transactions made via merchant devices (300) comprising merchant smartphones. Merchant devices (300) download and install as a transaction app (830) supported by an authentication service (840) in communication with each other when installed in the merchant device, and also with a payments server (100). The transaction app (830) requests purchases initiated using a customer card or device (300) at the merchant device (300). FIG 1 23

Description

ELECTRONIC PAYMENTS PLATFORM SYSTEM AND METHOD TECHNICAL FIELD

[0001] The present invention concerns electronic payments.

BACKGROUNDART

[0002] Retail electronic payments have conventionally involved considerable time and effort to orchestrate for accepting, processing and reconciling payments. Physical payment infrastructure is typically purpose-built using dedicated hardware devices embodying security principles to process payment transactions to an acceptable level of security and verification.

[0003] The PCI DSS (Payment Card Industry Data Security Standard) is a security standard developed and maintained by the PCI Council. Its purpose is to secure and protect the entire payment card ecosystem.

[0004] There is an underlying need for flexible and safe options for contactless payment acceptance, especially as regards payment in mobile environments. This has raised the possibility of payments incorporating COTS (commercial-off-the shelf) hardware devices. Also, adoption of contactless payments, sometimes termed tap and go, is increasing in existing payments systems as consumer acceptance increases.

[0005] Software-based PIN Entry on COTS (SPoC), and Contactless Payments on COTS (CPoC) solution certifications have allowed the possibility to build payment solutions on commercially available hardware. The PCI CPoC standard permits the possibility of using validated solutions that require no additional hardware to accept contactless transactions.

[0006] The PCI CPoC standard includes security requirements for vendors on how to protect payment data in CPoC Solutions and test requirements to evaluate these solutions through the supporting validation program.

[0007] The primary elements of a CPoC Solution include: a COTS device with an embedded NFC interface to read the payment card or payment device; a validated payment acceptance software application that runs on the merchant COTS device initiating a contactless transaction; and back-end systems that are independent from the COTS device and support monitoring, integrity checks and payment processing.

[0008] There are a number of limitations shared by existing electronic payments platforms. Many of these recognised limitations concern the dependence of many existing payments platforms upon dedicated and other tethered hardware.

[0009] These dedicated hardware solutions are for various reasons generally unsuitable or at best inconvenient for use in connection with events, especially outdoor events, but also existing indoor or mixed indoor-outdoor environments.

[0010] Retail and hospitality environments can benefit from the ability to take and process payments while with a customer, as this can be desirable for convenience and customer service reasons. Also, there is no need to return to crowd a central service counter.

[0011] One objective of the present invention is to at least attempt to address one or more of these and other limitations of existing electronic payment solutions.

SUMMARY OF INVENTION

[0012] According to an aspect of the present invention there is provided a computer-implemented method for operating an electronic payments platform comprising:

[0013] hosting a payments server accessible via the internet, the payments server operating a transaction service and a security service;

[0014] providing for download and installation to one of a plurality of merchant devices a transaction app supported by an authentication service at the merchant device, the authentication service being distinct from the transaction app and in communication with each other when installed in the merchant device, each of the transaction app and the authentication service when installed in the merchant device also being in communication with the payments server; and

[0015] configuring the transaction app when installed in the merchant device to transmit a request for a payment originating from the merchant device to a merchant acquirer service, wherein the transaction app authenticates payment details by invoking security services at the payments server via the authentication service at the merchant device.

[0016] A preferred embodiment involves the payments server requesting the security service to generate a merchant ID, the merchant ID indexing at least one of merchant data and device configuration to be stored at the security service.

[0017] A preferred embodiment involves the transaction app installed at the merchant device requesting the transaction service to request a registration code at the security service based upon the merchant ID, the registration being returned to the transaction app via the transaction service at the payment server.

[0018] A preferred embodiment involves the transaction app using the registration code returned from the payments server to register the transaction app at the security service via the authentication system.

[0019] A preferred embodiment is characterised by the payments server having multiple redundancies distributed across geographically distinct locations to enable uninterrupted processing in the event of failure at any specific location.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG 1 is a diagram depicting elements of the physical infrastructure for a payments platform according to an embodiment of the present invention.

[0021] FIG 2A is a diagram depicting a high-level schematic of a merchant device (and alternatively, a customer device) of FIG 1 when implemented as a smartphone.

[0022] FIG 2B is a diagram depicting a high-level schematic of a computer system of the type used in connection with the payments platform of FIG 1.

[0023] FIG 3 is a diagram depicting in overview a 3x3 architecture of a virtual server embodied in the physical infrastructure of FIG 1.

[0024] FIGS 4A-4C are diagrams depicting enumerated scenarios in which the virtual server of FIG 2 operates with one of the three Availability Zones is unavailable.

[0025] FIGS 5A-5C are diagrams depicting enumerated scenarios in which the virtual server of FIG 3 operates with two of the three Availability Zones is unavailable.

[0026] FIG 6 is a diagram depicting for completeness a high-level architecture of the server described and depicted with reference to FIGS 3-6.

[0027] FIG 7 is a diagram depicting in overview security measures for traffic control through security groups implemented in the server architecture of FIGS 3-6.

[0028] FIG 8 is a diagram depicting aspects of the logical layout of components comprising the payments platform of FIG 1.

[0029] FIG 9 is a flowchart outlining the process of transacting a payment in the payments platform of FIG 1.

[0030] FIG 10 is a database relationship diagram depicting the arrangement of data associated with the payments platform of FIG 1.

[0031] FIG 11 is a sequence diagram depicting a merchant onboading process associated with the payments platform of FIG 1.

[0032] FIG 12 is a sequence diagram depicting a terminal registration process associated with the payments platform of FIG 1.

[0033] FIGS 13A and 13B jointly present a sequence diagram depicting a payment transaction associated with the payments platform of FIG 1.

[0034] FIG 14 is a diagram depicting a security architecture of the payments platform of FIG 1.

[0035] FIGS 15A-15C depict user interface designs presented to a user during a process of creating an account.

[0036] FIG 16 depict user interface designs presented to a user when viewing transactions.

[0037] FIG 17 depicts user interface designs presented to a user when processing a refund.

[0038] FIG 18A-18C depicts user interface designs presented to a user when making payment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0039] FIG 1 depicts physical infrastructure associated with a payment platform of a preferred embodiment of the present invention.

[0040] A payments server 100, also for convenience referred to as simply server 100, communicates via network 200 to a merchant device 300, which in turn communicates as required with a customer device 400.

[0041] The payment platform hosts multiple merchant devices 300, and each such merchant device 300 communicates during the course of operation with various customer devices 400 to facilitate payments as described. As a matter of convenience, the singular and plural forms are used interchangeably herein for these components, namely merchant device 300, and customer device 400.

[0042] Server 100 is depicted in FIG 1 as a virtual server, specifically a VPC (virtual private cloud), as described in further detail below.

[0043] Network 200 comprises the public Internet (for convenience these terms are used interchangeably) and, as depicted, internet services accessible via mobile telephony networks such as 4G and 5G networks as are variously available. Network 200 is however not so limited and also embraces (for example) Internet access as may be provided by non-cellular wireless networks (Wi-Fi).

[0044] Merchant device 300 comprises an NFC-enabled terminal, and is typically an NFC-enabled smartphone. There exist a range of NFC-enabled mobile devices, principally embracing smartphones, and also smartwatches. Merchant device 300 may also comprise purpose-built NFC-enabled hardware (without voice services, for example) able to provide required services as described in context below.

[0045] Customer device 400 is an NFC-enabled payment card, such as credit card, debit card, and the like intended primarily to make payments. Customer device 400 is however not so limited and also embraces NFC-enabled devices such as smartphones and smartwatches and the like that are able to be configured to communicate with existing payment networks.

[0046] An NFC-enabled merchant device 300 communicates as required with various NFC-enabled customer devices 400.

[0047] NFC (near-field communication) is a set of communication protocols for communication between two electronic devices over a distance of 4 cm or less.

[0048] NFC offers low-power consumption, which is advantageous when the merchant device is a smartphone or smartwatch, or passive operation, which is advantageous when the customer device 400 is a card. No pairing is required.

[0049] An NFC chip - such as integrated with merchant device 300 - operates as one part of a wireless link, in conjunction another NFC chip - such as integrated with customer device 400 when the two devices 300, 400 are brought into sufficient proximity. Once activated, data can be shared between the two devices 300, 400 can be transferred when the devices 300, 400 are held a few centimetres from each other.

[0050] A customer device 400, whether a smartphone, smartwatch or payment card, operates to identify the customer and their relevant details, such as bank account and other associated information.

[0051] FIG 2A is a diagram of a high-level schematic of the merchant device 300 as embodied as a smartphone, and the description of merchant device 300 applies correspondingly to customer device 400 as embodied as a smartphone.

[0052] Merchant device 300 has an application processor 310. Application processor 310 is powered by power supply 320. Other elements of device 300 described below are also powered internally by power supply 320. Power supply 320 has a power management module 322 which communicates with application processor 310 and interconnects with battery 324. Power supply 320 is periodically recharged by an external supply (not shown) as required - via wired connection or inductively.

[0053] Storage 330 comprises volatile memory 332 and non-volatile memory 334, each of interoperate under direction from the application processor 310. The application processor 310 reads and writes data from and to volatile memory 332 and non-volatile memory 334.

[0054] Communications 340 comprises a RF (radio frequency) transceiver 342 which interoperates with application processor 310 through baseband processor 344 to co-ordinate transmission and reception of RF signals, principally establishing connection to a mobile network, such as via 4G or 5G protocols, for native voice communications and internet communication. Baseband processor 344 receives signals from the RF transceiver 342 and provides application processor 310 with corresponding data, and conversely receives data from application processor 310 and generals a corresponding signal for RF transceiver 342.

[0055] Other communications modules connected to application processor 310 include WLAN module 346, Bluetooth module 348, GPS module 352 and NFC module 354.

[0056] Interface 360 of the device 300 comprises a display processor 361 connected to the application processor 310, which is in turn connected to the display 362. Touch screen controller 363 is associated with display 362 and connected to application processor 310. Touch screen controller 363 receives user input, typically prompted by the content show to a user on the display 362.

[0057] Audio controller 364 connected to the application processor 310 processes between auditory signals and audio data sent to and received from application processor 310. Audio controller 364 in particular receives auditory output from the connected microphone 365, as well as generating auditory output to speaker 366.

[0058] Camera processor 367 is also connected to application processor 310 and also camera 368 for receiving visual input that is processed to be sent to application processor 310.

[0059] Physical buttons 369 such as on/off, volume or display brightness control provide input to application processor 310. Application processor 310 also provides signals to a haptic engine 371 that provides tactile feedback or kinaesthetic communication to a user holding device 300.

[0060] Device 300 embodies varies sensors 380 beyond those noted as part of the interface 360. These include accelerator 382, gyroscope 384, proximity sensor 386, barometer 388, ambient light sensor 392, and LiDAR scanner 394.

[0061] FIG 2B is a diagram depicting a high-level schematic of a computer system of the type used in connection with the payments platform of FIG 1, and referenced in the description that follows.

[0062] The representation presented abstracts various physical-layer hardware details, which may be variously implemented to provide required functionality.

[0063] Computer system 10 comprises a central processing unit 20 (CPU) that connects via a system bus (not shown) to a storage 30. Storage 30 comprises volatile memory 32, and non-volatile memory 34, each of which interoperates under direction of the CPU 20. The CPU 20 co-ordinates to read and write data records and application instructions to and from storage 30.

[0064] CPU 20 also interfaces with communications module 60, which comprises network interface controller (NIC) 62. NIC 62 transmits and receives data to and from network 200.

[0065] Computer system 10 also features an interface 40 as indicated which operates to interface with a user. CPU 20 connects to various elements of the interface 40 via an input/output bus (not shown). Display processor 41 is connected to CPU 20, which is also connected to the display 42.

[0066] Keyboard 43 and track pad 44 (alternatively, mouse 44) also connect to CPU 20, which provide input directly from a user to CPU 20, in response to what is depicted on display 42.

[0067] Audio controller 45 is connected to CPU 20, which processes between auditory signals and audio data sent to and received from CPU 20. Audio controller connects to speaker 46 and microphone 47. Audio controller 45 in particular receives auditory output from the connected microphone 47, as well as generating auditory output to speaker 46.

[0068] Bluetooth module 48 is connected to CPU 20 and provides near range wireless communications with external devices (not shown).

[0069] Camera processor 49 is connected to CPU 20 and also camera 50 for receiving visual input that is processed to be sent to CPU 20.

[0070] Computer system 10 is configured to be externally powered, with power distributed for operation for each of the described components.

[0071] FIGS 3-6 are diagrams that illustrate certain aspects of server 100 in some further detail. Server 100 in the preferred embodiment is supplied by Amazon Web Services (AWS), and the structure and operation of virtual server 100 is described in that context.

[0072] FIG 3 depicts a virtual server 100 comprising in the preferred embodiment a Virtual Private Cloud (VPC) configuration for workloads executed by AWS. A VPC is an AWS feature that enables one to launch AWS resources into a defined virtual network. It resembles having a network in a dedicated own data centre.

[0073] An Availability Zone is a set of distinct data centres over a geographical area that is safeguarded and administered by AWS, with three distinct Availability Zones A, B and C as depicted in FIG 3.

[0074] Amazon RDS (Relational Database Service) is a web service that establishes, operates, and scales a relational database in the AWS Cloud. Amazon RDS provides resizeable capacity for a relational database, and manages database administration tasks.

[0075] The architecture depicted is characterised as a 3x3 architecture as a consequence of having three Subnets provided on three Availability Zones.

[0076] Public Subnets (which are public-facing to the Internet 200) are denoted here as a, b, c and form a first layer. The Public Subnets are at the forefront as resources on this first layer subnet as they are dealing with direct web requests from the wider or public Internet 200. Load Balancers and Web Servers are located at the Public Subnets.

[0077] Private Subnets denoted here as a, b, c form a second layer. The Application Servers (or most of them) are hosted in this second layer. Access to these private subnets is trimmed down through their private IPs - and thus cannot be accessed from the public Internet 200). The last layer which is the Database subnets hosts the database or any other service that houses sensitive data, just like the private subnet, they do not have public IPs and can only be accessed privately.

[0078] The 3x3 server architecture depicted and described has various including but not limited to fault tolerance and high availability.

[0079] FIGS 4A-4C and FIGS 5A-5C depict enumerated scenarios in which either one (FIG 4) or two (FIG 5) of the three Availability Zones A, B, C of the VPC forming server 100 is unavailable. Unavailability is denoted by use of a heavy diagonal cross.

[0080] As will be appreciated from review of these scenarios depicted, successful process routing between the subnets can occur regardless of which of the Availability Zones A, B, C is unavailable. All that is required for continuous operation is one of Availability Zones A, B, C to remain available. The instance of the (available) Availability Zone A, B, C is immaterial in the scenarios as depicted.

[0081] FIG 6 builds on related FIGS 3-5 and depicts in fuller overview aspects of the VPC forming server 100, using the architecture of FIG 3, with Public Subnets a, b, c implement Amazon ALB, and the Private Subnets a, b, c implement Amazon EC2 (Elastic Compute Cloud), and the Database Subnets a, b, c also implement Amazon EC2. Requests are routed and serviced as indicated in and described with reference to FIGS 4-5. As indicated, the operation of the VPC is complemented by Amazon SNS and Amazon Cloudfront as described above.

[0082] FIG 7 depicts in overview security measures for traffic control through security groups implemented in the server architecture of FIGS 3-6. As indicated, the server 100 uses Amazon EC2, Amazon EBS (Elastic Block Store), and security groups to set the environment for its projects. Amazon EC2 is used for compute needs, and Amazon EBS is used for non-volatile storage and security groups as its firewall. A security group acts as a virtual firewall for an instance to control inbound and outbound traffic. At launch of an instance in a VPC of server 100, up to five security groups can be assigned to the instance. Security groups act at the instance level, not the subnet level.

[0083] As referenced above, Amazon EC2 is a web service that provides secure, resizable compute capacity in the cloud, and is designed to facilitate web-scale cloud computing for developers. Amazon EC2 launches as many or as few virtual server instances as required, appropriately configured. As a consequence, there is a scale up or down to accommodate changes in requirements that follow peaks and troughs of popularity, which as a consequence reduces the need to forecast traffic.

[0084] As also referenced above, Amazon EBS provides block level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes have like raw, unformatted block devices. These volumes can be mounted as devices on instances. Multiple volumes can be mounted on the same instance, but each volume can be attached to only one instance at a time. A file system can be created on top of these volumes or used in any way as with a block device (like a hard drive).

[0085] Beyond use of security groups as described in connection with FIG 7, traffic NACLs (network access control lists) are preferred (after applying security groups), though optional on account of applications being developed to be cloud-native.

[0086] NACLs provide an optional layer of security for the VPC and act as a firewall for controlling traffic in and out of one or more Subnets. NACLs can be applied with rules similar to security groups to add an additional layer of security to the VPC. TABLE 1 directly below outlines indicative traffic logic applied as a set of rules.

TABLE 1

sec-ops-site-dev

Inbound Outbound

Protocol Port Source Protocol Port Destination CIDR CIDR

HTTP 80 Office IP ALL ALL 0.0.0.0/0

HTTPS 443 Office IP

SSH 22 Office IP

MYSQL 3306 VPC CIDR

[0087] As regards operating systems, the Ubuntu operating system is preferred, though others may be used. TABLE 2 directly below indicates operating system services which are installed if not by default.

TABLE 2

Front end Back end

Nginx MySQL

PHP

Laravel

Redis

[0088] The platform uses third party services to provide additional functionality to its projects. Email, and SMS (Short Message Server) for communication to the customer for application use cases, as an example. Email and SMS functionality is for example is provided by Amazon SES (Simple Email Service) and Amazon SNS (Simple Notification Service). Amazon SES is an email platform that permits sending and receiving of email using specified email addresses and domains.

[0089] Amazon SNS is a web service that coordinates and manages the delivery or sending of messages to subscribing endpoints or clients.

[0090] The platform uses Load Balancers to achiever fault tolerance on the VPC 100. Redirecting traffic when one Availability Zone is unavailable for servicing requests ensures seamless operation of the platform in the event of failures.

[0091] Amazon Cloudfront is a CDN (content distribution network) for achieving high availability on the platform, and in particular fast content delivery to merchants and customers globally with low latency, high transfer speeds.

[0092] Amazon ALB (Application Load Balancer) makes routing decisions at the application layer (HTTOP/HTTPS) and supports path-based routing. Amazon ALB can route requests to one or more ports on each container instance in a cluster.

[0093] Amazon NLB (Network Load Balancer) makes routing decisions at the transport layer (TCP/SSL). Amazon NLB can handle millions of requests per second. After receiving a connection a target is selected from the target group for the default rule using a flow hash routing algorithm. A TCP connection is opened to the selected target on the port specified in the listener configuration. Amazon NLB forwards the request without modifying the headers.

[0094] FIG 8 depicts by way of overview other aspects of the operation of the payments platform of FIG 1.

[0095] Server 100 operates transaction services in the form of FINPAY Services (alternatively termed FINPAY Web) 810 and security services in the form of MPP Services 820. Both are hosted at server 100. A merchant uses merchant device 300, which hosts a transaction app in the form of FINPAY App 830 and an authentication service in the form of SOFTPos App 840. FINPAY App 830 is supported by SOFTPos App 840 within merchant device 300 to enable external authentication.

[0096] FINPAY App 830 preferably forms the transaction app installed and visible to users (merchants) on the merchant device 300, while SOFTPos App 840 preferably operates an as authentication service as a background service or framework hidden from merchants on the merchant device 300, and acts as a gateway or bridge to supporting hosted security services broadly indicated by MPP Services 820 at server 100, as broadly described above.

[0097] SOFTPos App 840 requests a transaction with MPP Services 820 when payment is initiated. MPP Services 820 in turn interacts with an Acquirer 850 (that is, a merchant acquirer service) representative of a banking services provider. The Acquirer 850 processes the underlying payment transaction, and fulfils the requested purchase, and handles refund or void or reversal transactions as required. Acquirer 850 is a banking institution or alternatively a payment gateway providing payment services.

[0098] MPP Services 820 also interacts with FINPAY Services 810 to complete tasks such as registering merchants, registering devices, checking device status and getting transaction details. FINPAY Services 810 is represented as drawing upon a database, representative of a data storage as outlined above in connection with server 100. Relevant details stored comprise merchant details and transaction details, which are drawn from Acquirer 850.

[0099] The merchant interacts not only with merchant device 300 but uses a Merchant Portal to interact with FINPAY Services 810 hosted at server 100.

[0100] FIG 9 is a flowchart that overviews the workflow of the payments platform described herein. At the START of the process, the merchant complete a login process in step 905 at merchant device 300 using the FINPAY App 830. The merchant makes a sale in step 910 using the FINPAY App 830.

[0101] The FINPAY App 830 makes a determination of whether or not the FINPAY App 830 is registered in step 915. Should be FINPAY App 830 not be registered If so, the process ENDS.

[0102] The process proceeds if the FINPAY App 830 if determined to be registered, and the merchant enters the input amount in step 920 for the transaction. The merchant selects a card in step 925, as nominated by the customer. An initialisation procedure is conducted at MPP Services 820 then proceeds in step 930. The actual transaction starts in step 935 following initialisation in step 930. The customer taps their card 400 in step 940. This is followed by the customer acting to input the PIN associated with card 400 in step 945.

[0103] A MPP transaction authorisation process is conducted in step 950, following which the process ENDS.

[0104] FIG 10 depicts a database structure as embodied by selected key tables in a relational structure, stored at server 100.

[0105] User table 1010 relational comprises fields of email, password and status. User table 1010 is stored in relation to other tables 1020-1080 comprising Business Profile table 1020, User Profile table 1030, Bank Account table 1040, Merchant

MPP Detail table 1050, Merchant MPP Setting table 1060, Terminal MPP Application table 1070 and Transaction MPP detail table 1080.

[0106] As indicated, User table 1010 is in direct relation to Business Profile table 1020, User Profile table 1030 and Bank Account table 1040 via primary key of userid. Merchant MPP Detail table 1050 is in direct relation to Merchant MPP Setting table 1060 and Terminal MPP Application table 1070 via primary key of merchant-mpp-detail_id. Terminal MPP Application table 1070 is in turn in direct relation to Transaction MPP detail table 1080 via primary key of terminal-mpp-appln-id.

[0107] Business Profile table 1020 stores various details about a business, as depicted, including trading name, business name, address, type, category and other details.

[0108] User Profile Table 1030 contains details about a merchant, such as first and last names, address, date of birth, telephone number and other details.

[0109] Bank Account table 1040 is presented and reserved for use though in a preferred embodiment remains unused as a consequence of the preferred mode in which the MPP App handles transactions without the need to store these details. Each of these tables 1020-1020 share primary key userid back to User table 1010.

[0110] Merchant MPP Detail table 1050 contains fields required for onboarding a merchant and getting the merchant id from the MPP Server in order for the merchant to prepare his account for integration of FINPAY-MPP SOFTPos integration.

[0111] Merchant MPP Setting table 1060 stores the default configuration of the terminal application through merchant onboading. Settings comprises account type selection available, available currencies, PIN entry timeout in seconds, shuffle PIN pad, and contact and contactless options.

[0112] Terminal MPP Application table 1070 is populated following onboarding once the merchant registers the FINPAY App into SOFTPos App. This table 1070 also contains information such as the registration code id, installation id and device id. The Terminal MPP Application table 1070 exists as the Merchant MPP Detail table 1050 can cater to many terminals.

[0113] Transaction MPP Detail table 1080 populates tables once a completed status is received from MPP Services 820.

[0114] FIG 11 is a sequence diagram depicting a merchant onboading process. A merchant activates an onboarding merchant process at FINPAY Web 810 via a merchant portal, which provides administrative functions, and a dashboard overview for the merchant account.

[0115] FINPAY Web 810 requests creation of a MPP Merchant ID at MPP Services 820, which returns to FINPAY Web 810 with a MPP Merchant ID. FINPAY Web 810 stores the Merchant ID.

[0116] FINPAY Web 810 sets the partner Merchant ID at MPP Services 820. Similarly, FINPAY Web 810 successively sets Merchant Data, and Device Configuration at MPP Services 820, and confirms to the merchant upon completion.

[0117] FIG 12 is a sequence diagram depicting a terminal registration process associated with the payments platform of FIG. 1. Merchant device 300 is used to initiate a process for registering the FINPAY App 830. A registration code is generated by the FINPAY App 830 and passed to FINPAY Web 810.

[0118] FINPAY Web 810 gets the MPP Merchant ID, and then creates an associated registration code, indicated by an MPP Merchant ID that is shared to MPP Services 820. A response to returned to FINPAY Web 810 from MPP Services 840.

[0119] Registration ID code is stored by FINPAY Web 810, and then also returned to FINPAY App 830 by way of response to the earlier request to generate a registration code.

[0120] FINPAY App 830 now commences an Interapp registration process: a request for interapp registration is sent from FINPAY App 830 to SOFTPos App 840.

[0121] SOFTPos App 840 registers itself with MPP Services 820, where registration completes, and a response returned to SOFTPos App 840. A response is in turn sent back from SOFTPos App 840 to FINPAY App 830.

[0122] FINPAY App 830 then requests installation status from FINPAY Web 810. FINPAY Web 810 then in turn requests installation status of MPP 820. MPP 820 returns with a response and installation code to FINPAY Web 810, which stores the installation ID returned from MPP 820. FINPAY Web 810 sends a partner terminal ID to MPP 820, which returns a response. FINPAY Web 810 returns a response to FINPAY App 830, which then passes a response to merchant device 300.

[0123] FIGS 13A and 13B jointly present a sequence diagram depicting a payment transaction associated with the payments platform of FIG 1.

[0124] First, turning to FIG 13A, a user using merchant device 300 selects payment on FINPAY App 830. Fl NPAY App 830 in turn makes a transaction request of FINPAY Web 810 at server 100. FINPAY Web 810 generates an installation ID, and also generates a transaction request at MPP 820. A response is returned from MPP 820 to FINPAY Web 810, and a transaction request ID supplied to FINPAY Web 810. FINPAY Web 810 stores the transaction request ID from MPP 820. A response or acknowledgement is returned from FINPAY Web 810 to FINPAY App 830 in response to the initial transaction request, described above.

[0125] At this point, an inter-app transaction request is made from FINPAY App 830 to SOFTPos App 840. SOFTPos App 840 starts a transaction with MPP 820, and receives an acknowledgement in reply to SOFTPos App 840. Local processing at SOFTPos App 840 proceeds, followed by a transaction request sent from SOFTPos App 840 to MPP 820.

[0126] MPP 820 makes an authorization request to the merchant acquirer 850. Authorisation proceeds at merchant acquirer 850, according to the internal processes of the merchant acquirer 850. An authorisation response is then transmitted from the merchant acquirer 850 to MPP 820, which in turn logs the authorised transaction. Once the transaction is logged at MPP 820, a response confirming authorisation of the transaction returns to SOFTPos App 840. The response is displayed on the merchant device 300. A record of transaction complete is sent from SOFTPos App 840 to MPP 820, with an acknowledgement sent in reply. SOFTPos App 840 sends a response to FINPAY App 830 acknowledging completion the inter-app transaction described above. Turning to FIG 13B, this response is also depicted here to indicte continuity with FIG 13A.

[0127] One a response is received from SOFTPos App 840, FINPAY App 830 generates a transaction response request which is sent to FINPAY Web 810. FINPAY Web 810 requests a transaction request status at MPP 820, and a response is returned to FINPAY Web 810 by way of a transaction ID. Similarly, a request for transaction details (indexed by this transaction ID is send from FINPAY Web 810 to MPP 820, and a response is returned to FINPAY Web 810 in the form of the requested transaction details. These transaction details may be optionally logged at FINPAY Web 810.

[0128] A response is then returned to FINPAY App 830 in reply to the initial transaction response request described above, and the result in the form the relevant transaction details displayed to the user at FINPAY App 830. Processing at the merchant device 300 completes.

[0129] FIG 14 depicts a security architecture of the payments platform of FIG 1. The architecture depicted and described provides supplemental detail to the representation presented and described above in connection with FIG 8. In particular, components associated with FINPAY App 830 are identified and demarcated from components associated with SOFTPos App 840.

[0130] Merchant device 300 hosts FINPAY App 830 and SOFTPos App 840, which each call upon MPP Embedded SPoC Libraries. These SPoC Libraries concern PIN Transaction Security (PTS) and Secure Card Readers (SCR).

[0131] Merchant Portal and FINPAY App 830 both interact with an API Layer at FINPAY Web 810 to achieve the enumerated processes described above in connection with onboarding merchants, registering installation of FINPAY App 830, requesting payments, authorising transactions and more generally monitoring and managing activity. The various card schemes depicted in FIG 14 are representative of merchant acquirer services, as part of communication between FINPAY Web 810 for authorizing transactions over PCI DSS.

[0132] SOFTPos App 840 communicates with MPP Services 820, broadly represented by components demarcated PCI-DSS. A Terminal App Services API interfaces with SOFTPos App 840.

[0133] FINPAY Web 810 via its API Layer interacts with MPP Services 820 depicted in dashed outline. As indicated, specific communications protocols used for onboarding merchants, registering installation, requesting payment and other tasks associated with generally monitoring and managing are HTTPS/RESTFUL JSON web services. Authorising transactions uses is conducted using TCP/IP IS08583.

[0134] MPP Services 820 relies upon different APIs to manage communications with FINPAY Web 810 and SOFTPos App 840. These include a Terminal App Services API for communication with SOFTPos App 840, and a Partner Services API for Transaction Processing API for communication with FINPAY Web 810. Partner Services API delivers services in connection with onboarding merchants, registering installation, requesting payment and other tasks associated with generally monitoring and managing. Transaction Processing API delivers services in connection with authorising transactions.

[0135] Requests via the above-mentioned APIs are serviced by an Attestation Component, a Transaction Management Component and a Monitoring Component. A further Crypto API is used at MPP Services 820 to communicate with Thales Payshield 9000 HSMS, which is a commercially available hardware security module (HSM) that performs such tasks as PIN protection and validation, transaction processing, mobile and payment card issuance, and key management.

[0136] FIGS 15A-15C depicts user interface designs presented when a user, namely a merchant, creates their account. A splash screen appears on the display 362 of merchant device 300 at pane #1 appears when the FINPAY App 830 is launched on the merchant device 300. As a matter of convenience, the term screen is used to refer to the temporary image appearing on physical touchscreen display 362.

[0137] A new user is invited to 'Create Account' at pane #2, or alternatively 'Log In'. A first screen for creating an account appears at pane #3, requiring entry of email address, and password, then tapping 'Next' to transition to pane #4. Business details are required in the successive screen at pane #4 - comprising country, trading name, business name, ABN and Address, which when completed permits for tapping 'Next' to transition to pane #5.

[0138] Further business details are entered by the user at pane #5, namely business type, business category, and estimated annual revenue. Again, on completed entry, tapping 'Next' transitions to pane #6.

[0139] Business ownership details are required at pane #6, comprising entry of fields for first name, last name, date of birth, address, phone number and role in business. On completed entry, tapping 'Next' transitions to pane #7.

[0140] Identification details are required for entry at pane #7, comprising an identification number and an underlying document. This may be passport, driver's licence, or Medicare details, by way of non-limiting example. On completed entry, tapping 'Next' transitions to pane #8.

[0141] Bank account details are required at pane #8, comprising account holder or name, BSB and account number. Again, on completed entry, tapping 'Continue' transitions to pane #9, or alternatively these details may be entered later by tapping 'Skip', which also transitions to pane #9.

[0142] A success confirmation screen is presented at pane #9, confirming account creation. The user taps 'Done' to transition to pane #10.

[0143] The user logins to the newly created account by entry of email address and password, and tapes 'Next' to transition to pane #11.

[0144] The user is promoted to receive Real-time notifications in pane #11. The user can tap either 'Turn on notifications' or 'Skip for now' to record their choice, either of which transitions to pane #12.

[0145] The user is prompted to verify their email address in pane #12, and can respond by either tapping 'Check Inbox'or 'Resend email'.

[0146] FIG 16 depicts user interface designs presented when a user namely a merchant reviews their transactions on the FINPAY App 830.

[0147] Transactions are presented in pane #1 and Cash transactions selected by default. The user can tap on 'QR Code', which transitions to pane #2 to present a different set of transactions, or tap on Card to transition to pane #3. The user can tap in the Search field to search for specific transaction, and the screen transitions to pane #4. Filtering options are presented in pane #4, which permit filtering by how recent the transactions were, or the amount of the transactions.

[0148] FIG 17 depicts user interface designs presented when a user, namely a merchant, seeks to make a refund on the FINPAY App 830. The process of generating a refund starts in pane #1. A user enters the amount to be refunded, in this example -$50.00 using the virtual touchscreen keypad of merchant device 300. The user taps 'Refund', which transitions to pane #2. The user is presented to option of selecting Cash or Card or Other as the refund type according to circumstances. Regardless of selection, the screen transitions to pane #3. The user selects from one of four options presented as radio buttons as to reason for refund - in this case, either Faulty Goods, Cancelled Order, Fraud, or Other. Once the selection is entered the screen transitions to pane #4 in the event that the option for Card refund was selected in pane #2 - a button is presented 'Enter Card Details' which transitions to a further screen (not shown) for the purpose of entering the card details of the card to which a refund is to be returned.

[0149] FIGS 18A-18C depict user interface designs presented when a user, namely a merchant, seeks to process a payment on the FINPAY App 830.

[0150] When seeking to initiate a payment, a user is prompted in pane #1 to Make a Sale, and enter an amount on the virtual keypad on the touchscreen of merchant device 300 the amount in dollars. The screen transitions to pane #2 once the user taps Charge. The user is prompted to tap which Type of Sale applies, with options available being Cash, QR Code or Card. The user taps the applicable option.

[0151] The screen transitions to pane #3 if a Cash payment applies, and pane #3 indicates the amount entered earlier in pane #1, and prompts the user to Confirm the payment.

[0152] The screen transitions to pane #4 if a QR Code payment applied at pane #2, and an applicable QR code is presented along with the applicable amount entered at pane #1, which can be displayed to the purchaser for completing payment.

[0153] Should the user have tapped Card at pane #2, the screen transitions to pane #5. The amount entered by the user at pane #1 is displayed at the top of pane #5. The user is given an option to tap Enter Card Details, or a prompt to tap the customer card 400 at the back of the merchant device 300 - be it a smartphone or reader. The customer taps their card 400, of the user taps Enter Card Details in which case the screen transitions to pane #6.

[0154] The customer or user may enter the card details of the customer card 400 - in this case, card number, expiry and CVV (Card Verification Value). The customer or user taps Charge, and the button by way of confirmation displays at right the amount set to be charged to the customer card 400.

[0155] After tapping Charge, the screen transitions to pane #7. The customer is presented the option of verifying acceptance of the charge by tapping Enter PIN or Signature in pane #7. Should the customer tap Enter PIN, the screen transitions to pane #8. The customer is prompted to enter the PIN associated with the customer card 400 via tapping the virtual keypad presented. Once the digits are entered the customer taps Confirm to complete.

[0156] Should the customer tap signature at pane #7, the screen transitions instead to pane #9. The customer is prompted to rotate the screen from portrait orientation to landscape orientation. Once the merchant device 300 registers a change in orientation as sensed via accelerometer 382 the screen transitions to pane #10. A rectangular landscape-oriented window is presented to the customer at pane #10, and the customer is prompted to draw their signature upon the touchscreen display 382. The customer taps Confirm to complete, and the screen transitions to pane #11.

[0157] The customer and merchant are presented in the usual course of events with a notification that the transaction is successful in pane #11. An option is presented to Send Receipt or Print Receipt. Should the merchant or customer tap Send Receipt, the screen transitions to pane #12.

[0158] The customer or merchant are presented with options to elect either Email or Text Message at this point.

[0159] The foregoing description concerns a preferred embodiment only. As will be appreciated many modifications or alternatives may be made without departing from the present invention.

Claims (5)

CLAIMS The claims defining the invention are as follows:

1. A computer-implemented method for operating an electronic payments platform comprising: hosting a payments server accessible via the internet, the payments server operating a transaction service and a security service; providing for download and installation to one of a plurality of merchant devices a transaction app supported by an authentication service at the merchant device, the authentication service being distinct from the transaction app and in communication with each other when installed in the merchant device, each of the transaction app and the authentication service when installed in the merchant device also being in communication with the payments server; and configuring the transaction app when installed in the merchant device to transmit a request for a payment originating from the merchant device to a merchant acquirer service, wherein the transaction app authenticates payment details by invoking security services at the payments server via the authentication service at the merchant device.

2. A computer-implemented method as claimed in claim 1, wherein at the payments server the transaction service requests the security service to generate a merchant ID, the merchant ID indexing at least one of merchant data and device configuration to be stored at the security service.

3. A computer-implemented method as claimed in claim 2, wherein the transaction app installed at the merchant device requests the transaction service to request a registration code at the security service based upon the merchant ID, the registration being returned to the transaction app via the transaction service at the payments server.

4. A computer-implemented method as claimed in claim 3, wherein the transaction app uses the registration code returned from the payments server to register the transaction app at the security service via the authentication system.

5. A computer-implemented method as claimed in any one of claims 1 to 4, wherein the payments server is characterised by multiple redundancies distributed across geographically distinct locations to enable uninterrupted processing in the event of failure at any specific location.