WO2020254761A1 - Système d'applications de service pour terminaux de paiement - Google Patents

Système d'applications de service pour terminaux de paiement Download PDF

Info

Publication number
WO2020254761A1
WO2020254761A1 PCT/FR2020/051051 FR2020051051W WO2020254761A1 WO 2020254761 A1 WO2020254761 A1 WO 2020254761A1 FR 2020051051 W FR2020051051 W FR 2020051051W WO 2020254761 A1 WO2020254761 A1 WO 2020254761A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
payment
software module
service platform
platform
Prior art date
Application number
PCT/FR2020/051051
Other languages
English (en)
Inventor
Amilcar BATISTA
Original Assignee
Aava Mobile Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aava Mobile Sas filed Critical Aava Mobile Sas
Priority to EP20785770.7A priority Critical patent/EP3987390A1/fr
Priority to AU2020296966A priority patent/AU2020296966A1/en
Priority to CA3143068A priority patent/CA3143068A1/fr
Priority to US17/621,337 priority patent/US20220366393A1/en
Priority to BR112021025579A priority patent/BR112021025579A2/pt
Publication of WO2020254761A1 publication Critical patent/WO2020254761A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F9/00—Details other than those peculiar to special kinds or types of apparatus
    • G07F9/006—Details of the software used for the vending machines
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00—Cash registers
    • G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]

Definitions

  • the present invention relates to the field of service applications for payment terminals.
  • a payment terminal is a computer device allowing a professional to manage the electronic payment of a good or a service by a customer. Payment is typically made using a bank card, smartphone or any other medium carrying a means of payment. The card, its holder and the transaction are authenticated and validated by the payment terminal with a banking service, after presentation of the card at the terminal, or manual entry of information relating to the identification of the holder (card number, date expiration date, bearer ID, etc.).
  • the payment terminal can be made up of a dedicated computing device, can be made up of a general purpose computing device, such as for example a mobile phone, a computing tablet, a personal computer equipped with a means of reading a chip card.
  • a magnetic stripe card contactless and generally reading information on a medium allowing the identification of a customer to the banking service (including bar code or QR code), or an application allowing access to the payment service (example: internet browser) and connected to a computer network.
  • the IT device has a service application dedicated to transaction management.
  • the current context of payment is marked by the appearance of new means of payment such as, for example, payment solutions using connected objects such as smart phones (smartphones in English) with payment capabilities.
  • new means of payment such as, for example, payment solutions using connected objects such as smart phones (smartphones in English) with payment capabilities.
  • Apple Pay registered trademark
  • Android Pay registered trademark
  • electronic wallet solutions international regional or affinity
  • AliPay registered trademark
  • WeChat Pay registered trademark
  • Paypal registered trademark
  • BlueCode registered trademark
  • Paylib registered trademark
  • VISA registered trademark
  • VISA Electron registered trademark
  • MasterCard registered trademark
  • Maestro registered trademark
  • Union Pay registered trademark
  • Discover registered trademark
  • American Express registered trademark
  • Bank cards registered trademark
  • MultiBanco registered trademark
  • Giromat registered trademark
  • Giropay registered trademark
  • Services around payment are also developing, such as the offer of payment in installments, payment in foreign currency (DCC), deferred payment, etc.
  • Services ancillary to the transaction itself are also developing, such as the offer of insurance on the good or service purchased, warranty extensions, support for tips.
  • These ancillary services may also relate to customer relations, such as loyalty programs, the offer of discount coupons, the collection of customer reviews or others.
  • Still other services may relate to consumer knowledge and consumer behavior. The possibilities for payment services are constantly increasing.
  • the object of the present invention is to resolve the aforementioned drawbacks by proposing a service platform that can be integrated into a payment or customer interaction solution.
  • the platform also offers a tool for graphical programming of payment solutions which allows a user of the platform to define payment solutions by integrating the desired services and configuring them.
  • This graphical programming tool can be used without requiring any computer knowledge.
  • the graphical programming tool makes it possible to generate at least two software, for example based on scripts, one intended to be executed on the payment terminal and to collaborate with the other on a server of the services platform to provide a payment solution.
  • a professional can easily and quickly define the payment solution adapted to his needs.
  • This solution can be deployed quickly. It can also be modified at any time by the professional in order to follow changes in his needs.
  • Figure 1 illustrates the architecture of a service system for payment terminals according to an exemplary embodiment of the invention.
  • Figure 2 illustrates an example of a programming interface for payment terminal service applications.
  • FIG 3 illustrates a service as it appears in the edit window according to an exemplary embodiment of the invention.
  • Figure 4 illustrates the deployment of the service application according to one embodiment of the invention.
  • FIG 5 illustrates the flow of a service, here the payment service, according to an exemplary embodiment of the invention.
  • FIG 6 illustrates the main steps in running a service application in one embodiment of the invention.
  • FIG 7 illustrates the software architecture of the payment terminal in an exemplary embodiment of the invention.
  • FIG 8 illustrates the software architecture of the server platform in an exemplary embodiment of the invention.
  • FIG 9 is a schematic block diagram of an information processing device for the implementation of a payment terminal or a server that can implement the service platform for payment terminals according to several embodiments of the invention.
  • Figure 1 illustrates the architecture of a service system for payment terminals according to an exemplary embodiment of the invention.
  • the system includes a service platform 103.
  • This service platform includes a first execution module 105 which enables the operation of payment services at a payment terminal 101.
  • the service platform 103 also includes a payment service programming module 104 to which a user, that is to say a person operating a payment terminal 101, can connect from an information processing device 102.
  • This The device may typically consist of a personal computer, a tablet, or any terminal that can connect to an Internet type data communication network.
  • the information processing device typically has an Internet client, such as a web browser, allowing the user to interact with the payment services programming module 104.
  • the service platform 103 is described here in a logical manner. It may consist of one or more servers interacting to provide the service described. Likewise, only the aspects essential to the definition and then to the execution of payment service applications are described.
  • the platform also includes ancillary services such as, for example, authentication and user management which are not described in detail.
  • the payment services programming module 104 allows the user to program in a simple, intuitive and rapid way, a payment service based on basic services offered by the service platform 103.
  • the payment services programming module offers graphic programming by arrangement of elementary services, their connection and the definition of their parameters.
  • This complete application once defined, consists of two software modules one intended to be executed on the payment terminal 101 and the other on the execution module 105. The two software modules then interact to jointly execute the application.
  • the application involves more than two software modules running on different computing devices and interacting with each other.
  • At least some of the elementary services constituting the application for a payment terminal can call on one or more external services 106 to 109.
  • These external services include, for example, payment service providers (PSP for Payment Service Provider), electronic mail services, short text message messaging services (SMS for Short Message Service), customer opinion collection and analysis services, sales promotion services (loyalty program, management of coupons %), customer identification services (eg: token management) or others.
  • a user operating a payment terminal can use the platform to define a complete application for a payment terminal.
  • This definition does not require any particular programming knowledge, it is quick and easy to use.
  • the platform Once the application is defined, the platform generates all the software modules that must run on the payment terminal.
  • the platform also generates a second software module that runs on the platform itself.
  • the software modules intended for the payment terminal or, more generally, any computer device, are deployed on them.
  • the software module deployed on the terminal runs, connects to the platform and cooperates with the software module running on the platform to provide the services making up the application. Some of its services may use external services that interact with the service platform.
  • the user can therefore, at any time, define or modify his payment application to adapt to the evolution of his needs and to offer the desired level of service to his customers.
  • New services appearing on the market can be offered quickly by integration with the service platform. From this integration done, users can integrate them into their payment terminal application.
  • Figure 2 illustrates an example of a service application programming interface for payment terminals.
  • the graphical programming application for programming service applications operates in a client-server mode between the client 102 used by the user and the programming module 104 on the service platform.
  • the example described here is based on the use of a standard web browser on the client 102 interacting with a programming module 104 developed as a web service on the platform. Any other implementation is of course possible, such as a native client interacting with a native application on the server side for example.
  • the programming interface includes a main window
  • a first sub-window 202 comprises a list of the elementary services 203 available.
  • this list can be ordered by type of service.
  • the list can be hierarchical and make it possible to display only the services of the same category at a given time to facilitate the identification of the service sought, if the total number of services is large.
  • a second sub-window 204 allows editing of the service application for payment terminals. In this edit window 204, the user can arrange 205 services selected from the list of services 202. Typically, the user can select a service from the list of services.
  • the service 205 once dropped into the edit window exposes at least one entry point and at least one exit point, as well as possible end points. branching (hooks in English). The user can then connect the entry and exit points of the various services to constitute his application.
  • the services 205 also expose, if necessary, a set of parameters allowing the user to customize the service according to his needs.
  • the interface also includes, not shown in the figure, the controls allowing the saving of an application as well as the generation and the deployment of software modules generated on the payment terminal and on the platform.
  • the deployment of the software module intended for the payment terminal can be carried out on a set of payment terminals, for example in the case of a store comprising a set of payment terminals or in the case of a chain of stores.
  • Figure 3 illustrates a service 301 as it appears in the edit window 204 according to an exemplary embodiment of the invention.
  • the service includes at least one entry point 304 and at least one exit point 305.
  • exit point # 3 transaction canceled by client
  • One or more branch points 306 may be present. These connection points allow the service to be interrupted at a given time to trigger the progress of one or more other services connected to that connection point. When these services end, the interrupted service is resumed.
  • the service comprises an identification zone 302.
  • This identification zone can include the name of the service, an identifier of the service as well as a long description of the service.
  • a button in this area opens a help page which gives details of the operation of the service to the user.
  • a service configuration area 303 is present if the service can be configured.
  • This configuration area typically includes controls, such as drop-down menus, multiple or exclusive selection check boxes, numeric or text fields, etc. The user can then easily configure each service according to their needs.
  • a payment service could allow the user to choose the type of card accepted from contactless smart cards, contactless, magnetic cards and manual entry, etc. It can also allow choose the solutions accepted among, for example, the solutions VISA, MasterCard, American Express, Discover, JCB ...
  • the types of payment accepted can also be configured from different types (example: debit, credit, reimbursement ).
  • Default parameters can also be set. Connection points can be offered to allow the insertion of other services at certain times during the execution of a service (eg payment) payment such as, for example, before insertion of the card, after insertion of the card, before selection of the application and after selection of the authorization.
  • a currency conversion service can be connected to the intervening branch point. After inserting the card.
  • the customer will be offered the selection of a currency, for example US dollar, instead of the merchant's default currency, for example euro.
  • the customer can then read on the terminal the net amount which will be withdrawn from his bank account in his currency and including any costs such as the exchange rate and the exchange commission.
  • Figure 4 illustrates the deployment of the service application according to one embodiment of the invention.
  • the software module 402 is intended to be executed on the payment terminal 404 (or other computer device) under the control of a service orchestra 406.
  • the software module 403 is intended to be executed on the server (or other device). IT) within the service execution module 405, corresponding to the module illustrated in Figure 1 under the reference 105.
  • the software module 403 is executed under the control of a service orchestra 407.
  • the software modules 402 and 403 are composed of a set of resources comprising scripts, files (eg: images, configuration file, etc.), and a workflow (workflow in English ) which defines the scheduling of services.
  • Each script is configured according to the parameters defined by the user.
  • Each service used therefore results in a first script running on the payment terminal (or other IT device) and a second script running on the platform (or other IT device). At least one IT device is mandatory.
  • These scripts cooperate through connection 408 between computing devices.
  • the script can also cooperate with external services as explained in relation to Figure 1.
  • the user of the payment terminal uses an application which seems to him to be executed on said terminal but which ultimately implements software modules local to the terminal, others on the service platform and potentially external services.
  • the 406 and 407 service orchestras running on the computing devices respectively, are in charge of executing the different scripts that make up the different services in accordance with the defined workflow. These service orchestras also execute the scripts with the parameters corresponding to the programming of the application made in the programming module 104.
  • Scripts that run on computing devices can be programmed in the same scripting language or else in different languages depending on the embodiments of the invention. This choice depends on the software choices, in terms of operating system and software environment made for the payment terminal and for the platform. These scripting languages include, for example, Javascript, Lua, Python, Kotlin, Groovy or others. In some embodiments, actual executables can be compiled in lieu of scripts.
  • Figure 5 illustrates the progress of a service, here the payment service, according to an exemplary embodiment of the invention.
  • the terminal initiates the execution of the service by the processing block 501.
  • the processing block 501 requests the insertion of the card from the customer.
  • the card is then read and the default currency of the card is extracted. If an external service is connected to the connection point “after insertion of the card”, then this service is triggered.
  • the customer's PIN code is then verified. If the customer's PIN code is verified successfully, an authorization request 502 is sent to the corresponding script which is executed on the platform.
  • This script running on the platform, performs a processing block 503.
  • This processing block is responsible for selecting the bank that must process the payment.
  • the script running on the platform must use other services available on that platform.
  • the platform includes a database containing the reference of the banks with which the merchant has signed an acquisition contract.
  • This database also contains technical information for connecting to banks, such as primary and secondary IP addresses and login credentials.
  • acquisition contracts can be modeled in order to be able to assess which bank is the most competitive for a given type of transaction. For example, an international "VISA" payment may be cheaper with one bank while a "MasterCard" payment will be cheaper with another bank.
  • the processing module 503 chooses a bank and transmits the payment request 504 to it.
  • the chosen bank then processes the request during processing 505.
  • the payment is validated or refused.
  • the bank transmits this result in a 506 response to the platform.
  • the platform, during processing 507 retransmits the response 508 to the payment terminal.
  • Figure 6 illustrates the main steps in running a service application in one embodiment of the invention.
  • a transaction is initiated.
  • the orchestra of services of the payment terminal launches the first script making up the application.
  • the terminal services orchestra is in charge of successively launching the services as they are executed on the payment terminal or computing device.
  • a strong authentication can be used to authenticate the payment terminal with the platform.
  • this authentication uses a cryptographic system (eg asymmetric keys) managed within a secure hardware module.
  • This secure hardware module is made up of a physical part and a software part whose role is to protect the keys and cryptographic operations. Any attempt at logical or physical intrusion of a secure hardware module can lead to the immediate erasure of the cryptographic keys it contains.
  • Such a secure hardware module is functionally very close to a smart card while having a greater processing capacity.
  • step 605 the application context, that is to say, typically, the list of data captured and / or generated by the application, is transferred to the server.
  • the platform's service orchestra identifies the server script corresponding to the service application based on the identification of the payment terminal and launches it with the associated parameters.
  • step 608 the application is executed by orchestrating the various service scripts on the payment terminal and on the platform. If necessary, scripts running on the platform call on external services as described in relation to Figure 5.
  • step 609 symmetrical to step 604, a connection to the client is initiated by the server.
  • step 610 symmetrical to step 605, the server application context is transferred to the client.
  • Steps 602 through 610 can be performed any number of times depending on the needs of the application.
  • step 606 at the end of the application, the client script initiates the end of execution.
  • the platform is notified of the end of execution and can then release the resources used by the script on the platform.
  • the same service orchestra is deployed on the client and the server or servers.
  • the application is then seen as a set of a or several software modules running on one or more computer devices and working together according to the needs of the application.
  • the passage of control from one device to another is done as illustrated in FIG. 6 between the client and the server.
  • the transaction can then be initiated either by one or the other of these software modules.
  • a store sign could deploy an instance of the service orchestra on each of the payment terminals, an instance of the service orchestra on a server within each store and an instance on a remote central server. .
  • the application would then be made up of all the software modules executed on each of these instances of the service orchestra.
  • an instance of the service orchestra would be deployed on each payment terminal, only one of these terminals would be connected to the Internet.
  • the instance deployed on the payment terminal connected to the internet would then act as a proxy for the other instances.
  • Several terminals then collaborate in carrying out the transaction.
  • a store has a screen equipped with an NFC reading means, a payment terminal having all the means to validate a payment which communicates with a remote server.
  • NFC reading means an NFC reading means
  • a payment terminal having all the means to validate a payment which communicates with a remote server.
  • Figure 7 illustrates the software architecture of the payment terminal in an exemplary embodiment of the invention.
  • the payment terminal operates under the control of Google's Android operating system (registered trademarks).
  • This operating system 700 makes it possible to operate a set of software modules necessary for the operation of service applications according to the exemplary embodiment of the invention. These modules are implemented in the form of one or more Android applications depending on the embodiments.
  • the central module is the service orchestra 704. It is this module which loads the various scripts constituting the service application, which allows them to be executed. and schedule them. To do this, the service orchestra 704 includes an execution engine of the chosen scripting language:
  • the terminal has to process scripts that it is the only one able to execute because they call on resources only available in the terminal (eg: communication with the smart card reader).
  • scripts can only be executed by the server (eg connection to a third party service hosted outside the server environment and not accessible by the terminal.
  • scripts can run on the terminal or on the server.
  • a transaction therefore consists of 3 major elements:
  • the scripts are available in both environments (i.e. terminal and server) before the start of a transaction in order to reduce the delay in starting the transaction. However, it is also possible that the terminal downloads the scripts and the "workflow" at the start of a transaction.
  • the service orchestra is responsible for transferring the context from the terminal to the server (and vice versa) during the "handover".
  • the service applications share a number of common functionalities made available either by the terminal or by the server. They must all access the payment card reader integrated into the terminal, communicate with the service platform, manage the terminal interface or even manage cryptographic operations as part of their authentication with the platform, for example.
  • These common functionalities are provided by a set of software modules typically grouped together in one or more Android applications, or “server” services.
  • a man-machine interface module (HMI) 702 provides the functions for managing the screen of the payment terminal as well as the keyboard. This module allows interactions with the user client of the terminal.
  • a security module 705 manages the cryptographic operations linked to the operation of the services. These operations include authentication with the platform and if necessary with third-party services.
  • This security module can interact with a secure microcontroller 708 present in the terminal and acting as a security element, that is to say a hardware component responsible for the actual cryptographic operations and the storage of the keys. , this component being equipped with security features designed to make it tamper-proof.
  • the card reader integration module 703 offers interactions with the card reader (s) present in the payment terminal. These readers can be wired or wireless.
  • the 706 Platform Interface Module provides communications with the platform. This is typically the module that will allow a client script to communicate with the corresponding server script and via this server script with any third party services.
  • a 701 update module is used to update workflows, scripts and various modules when new versions are available.
  • a communication module 707 manages the communications between these different modules and the exterior of the payment terminal and in particular the card reader and the service platform. It is this module that establishes secure communication tunnels, for example with the platform.
  • Figure 8 illustrates the software architecture of the server platform in an exemplary embodiment of the invention. This figure does not illustrate the programming module 104 but only the architecture useful for the execution of the service applications.
  • the core 800 of the platform is made up of a set of modules. These core modules include the 803 service orchestra which manages the loading, execution and scheduling of application server scripts. on duty. It is the server-side counterpart of the 704 service orchestra on the terminal.
  • scripts running on the platform can use a set of services available to them in the form of accessible software modules.
  • These services include an 801 authentication module that manages authentications.
  • This module typically cooperates with a secure hardware module 809 (HSM for Hardware Secure Module in English).
  • HSM Hardware Secure Module in English.
  • This authentication module will manage cryptographic operations on behalf of all modules that require it.
  • the 801 and 802 modules are the access point to the 809 module. They are responsible for preparing and optimizing the operations delegated to the 809 module (eg: converting data from XML or JSON format into a single binary format suitable for HSM).
  • a monitoring module 804 allows you to monitor the execution of scripts and the use of various modules and scripts during execution to detect possible anomalies that may arise from malfunctions or possible attacks on the platform.
  • modules are also present, not shown, such as for example a module for recording the technical and business operations carried out (log in English), a possible protocol translation module if necessary to interact with certain third-party services, a module for update of software components. This list is not exhaustive.
  • IP address IP address
  • authentication token MAC address
  • a module 805 manages the platform's communications with traders. It is this module which manages the communication with the payment terminals 810 within the framework of the execution of the service applications. It is also this module which manages the administration by a merchant of his service from an administration terminal 81 1.
  • a module 806 manages the platform's communications with third-party services. These services are typically requested by scripts executed by the platform's orchestration service when running service applications. Among these third-party services, mention may be made of an electronic mail management service 812, banking services 813 such as payment services, and merchant electronic services. These services also include services such as a merchant's 814 extranet. Indeed, certain service applications may require data specific to the merchant, for example to apply rules such as the attribution of a promotion according to criteria specific to the merchant, or even the proposal of a questionnaire to customers who have spent in less 100 euros in the month.
  • the platform also includes a module 807 which gives access to the manager of the platform for his administration.
  • these different modules are implemented in the form of services in a service oriented architecture (SOA). All of these services communicate, for example, through a message broker.
  • the operating system is Linux
  • the hypervisor managing server virtualization is Proxmox in development and VMWare in production
  • the services are managed by Kubernetes / Docker
  • the message service is ActiveMQ
  • the services are developed in Java / Spring, Node.js and / or C / C ++
  • the database can be Cassandra, MongoDB or ElasticSearch.
  • the proposed system allows a merchant to quickly define a service application (also called a “workflow”) for his terminals. payment, to deploy it without delay. Then this app can be changed at any time. New services appearing on the market can be integrated into the platform and made available to merchants who can then integrate it into their payment application. All this can be done without having to bear the costs and delays associated with the development of proprietary service applications.
  • a service application also called a “workflow”
  • FIG. 9 is a schematic block diagram of an information processing device 900 for implementing one or more embodiments of the invention.
  • the information processing device 900 may be a peripheral such as a microcomputer, a workstation or a mobile telecommunications terminal.
  • the device 900 has a communication bus connected to:
  • a central processing unit 901 such as a microprocessor, denoted CPU;
  • RAM random access memory 902
  • the executable code of the method for carrying out the invention as well as the registers adapted to record the variables and parameters necessary for the implementation of the method according to embodiments of invention
  • the memory capacity of the device can be supplemented by an optional RAM memory connected to an expansion port, for example;
  • ROM read only memory 903, denoted ROM, for storing computer programs for the implementation of the embodiments of the invention
  • a network interface 904 is normally connected to a communication network on which digital data to be processed are transmitted or received.
  • Network interface 904 may be a single network interface, or composed of a set of different network interfaces (eg, wired and wireless, interfaces or different types of wired or wireless interfaces). Data packets are sent over the network interface for transmission or are read from the network interface for reception under the control of the software application running in processor 901;
  • a user interface 905 for receiving input from a user or for displaying information to a user
  • the executable code can be stored in a read only memory 903, on the storage device 906 or on a digital removable medium such as for example a disk.
  • the executable code of the programs can be received by means of a communication network, via the network interface 904, in order to be stored in one of the storage means of the communication device 900, such as the storage device 906, before being executed.
  • the central processing unit 901 is adapted to control and direct the execution of instructions or portions of software code of the program or programs according to one of the embodiments of the invention, instructions which are stored in one. of the aforementioned storage means. After power-up, the CPU 901 is able to execute instructions from the main RAM 902, relating to a software application. Such software, when executed by processor 901, causes the described methods to be performed.
  • the apparatus is a programmable apparatus which uses software to implement the invention.
  • the present invention can be implemented in hardware (eg, in the form of a specific integrated circuit or ASIC).

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne une plateforme de services pouvant être intégrés à une solution de paiement. La plateforme offre également un outil de programmation graphique de solutions de paiement qui permet à un utilisateur de la plateforme de définir une solution de paiement en intégrant les services souhaités et en les paramétrant. Cet outil de programmation graphique peut être utilisé sans nécessiter de connaissance informatique. L'outil de programmation graphique permet de générer deux logiciels, par exemple à base de scripts, l'un destiné à être exécuté sur le terminal de paiement et à collaborer avec l'autre sur un serveur de la plateforme de services pour fournir une solution de paiement.

Description

Description
Titre de l’invention : Système d’applications de service pour terminaux de paiement
Domaine technique
La présente invention concerne le domaine des applications de service pour terminaux de paiement.
Technique antérieure
Un terminal de paiement (ou terminal de paiement virtuel) est un dispositif informatique permettant à un professionnel de gérer le paiement électronique d’un bien ou d’un service par un client. Le paiement s’effectue typiquement à l’aide d’une carte bancaire, smartphone ou tout autre support embarquant un moyen de paiement. La carte, son porteur et la transaction sont authentifiés et validés par le terminal de paiement auprès d’un service bancaire, après présentation de la carte au terminal, ou saisie manuelle des informations relatives à l’identification du porteur (numéro de carte, date d’expiration, identifiant du porteur, etc.). Le terminal de paiement peut être constitué d’un dispositif informatique dédié, être constitué d’un dispositif informatique généraliste, comme par exemple un téléphone mobile, une tablette informatique, un ordinateur personnel doté d’un moyen de lecture d’une carte à puce, d’une carte à piste magnétique, sans contact et de manière générale de lecture d’une information sur un support permettant l’identification d’un client au service bancaire (y compris code barre ou QR code), ou d’une application permettant l’accès au service de paiement (exemple : navigateur internet) et connecté à un réseau informatique. Le dispositif informatique dispose d’une application de service dédiée à la gestion des transactions.
Le contexte actuel du paiement est marqué par l’apparition de nouveaux moyens de paiement comme, par exemple, les solutions de paiement utilisant des objets connectés comme les téléphones intelligents ( smartphones en anglais) dotés de capacités de paiement. On peut citer les solutions Apple Pay (marque déposée), Android Pay (marque déposée), des solutions de portefeuille électroniques internationaux, régionaux ou affinitaires comme AliPay (marque déposée), WeChat Pay (marque déposée), Paypal (marque déposée), BlueCode (marque déposée), Paylib (marque déposée), etc.
De nombreuses marques de paiement se développent également comme, par exemple, VISA (marque déposée), VISA Electron (marque déposée), MasterCard (marque déposée), Maestro (marque déposée), Union Pay (marque déposée), Discover (marque déposée), American Express (marque déposée), Cartes bancaires (marque déposée), MultiBanco (marque déposée), Giromat (marque déposée), Giropay (marque déposée), etc.
Les services autour du paiement se développent également, comme l’offre de paiement en plusieurs fois, le paiement en devise (DCC), le paiement différé, etc. Les services annexes à la transaction proprement dite se développent aussi, comme l’offre d’assurances sur le bien ou le service acheté, les extensions de garantie, la prise en charge du pourboire. Ces services annexes peuvent également concerner la relation client, comme par exemple les programmes de fidélité, l’offre de coupons de réductions, la collecte d’avis client ou autres. D’autres services encore peuvent concerner la connaissance du consommateur et de son comportement. Les possibilités de services autour du paiement ne cessent de s’accroître chaque jour.
Pour pouvoir être offerts à ses clients de façon plus simple, intuitive et ergonomique, ces services doivent être intégrés à l’application de gestion du terminal du paiement par le professionnel. Pour ce faire, il est nécessaire de faire appel à des intégrateurs ou directement au fabricant du terminal de paiement pour développer une application spécifique correspondant aux besoins du professionnel. Ces développements sont longs, coûteux, et doivent ensuite être maintenus par un professionnel. Ce coût, ces délais et le manque de flexibilité sont un obstacle à l’adoption rapide par les professionnels des services disponibles ou à venir.
Exposé de l’invention
La présente invention a pour but de résoudre les inconvénients précités en proposant une plateforme de services pouvant être intégrés à une solution de paiement ou d’interaction client. La plateforme offre également un outil de programmation graphique de solutions de paiement qui permet à un utilisateur de la plateforme de définir les solutions de paiement en intégrant les services souhaités et en les paramétrant. Cet outil de programmation graphique peut être utilisé sans nécessiter de connaissance informatique. L’outil de programmation graphique permet de générer au moins deux logiciels, par exemple à base de scripts, l’un destiné à être exécuté sur le terminal de paiement et à collaborer avec l’autre sur un serveur de la plateforme de services pour fournir une solution de paiement.
Ainsi, un professionnel peut facilement et rapidement définir la solution de paiement adaptée à ses besoins. Cette solution peut être déployée rapidement. Elle peut également être modifiée à tout moment par le professionnel de façon à suivre les évolutions de ses besoins.
Brève description des dessins
[Fig 1 ] La figure 1 illustre l’architecture d’un système de services pour terminaux de paiement selon un exemple de réalisation de l’invention.
[Fig 2] La figure 2 illustre un exemple d’interface de programmation des applications de services pour terminaux de paiement.
[Fig 3] La figure 3 illustre un service tel qu’il apparaît dans la fenêtre d’édition selon un exemple de réalisation de l’invention.
[Fig 4] La figure 4 illustre le déploiement de l’application de service selon un mode de réalisation de l’invention.
[Fig 5] La figure 5 illustre le déroulement d’un service, ici le service de paiement, selon un exemple de réalisation de l’invention.
[Fig 6] La figure 6 illustre les principales étapes de l’exécution d’une application de service dans un mode de réalisation de l’invention.
[Fig 7] La figure 7 illustre l’architecture logicielle du terminal de paiement dans un exemple de réalisation de l’invention.
[Fig 8] La figure 8 illustre l’architecture logicielle de la plateforme serveur dans un exemple de réalisation de l’invention.
[Fig 9] La figure 9 est un bloc-diagramme schématique d'un dispositif de traitement de l’information pour la mise en œuvre d'un terminal de paiement ou d’un serveur pouvant implémenter la plateforme de service pour terminaux de paiement selon plusieurs modes de réalisation de l'invention.
Description détaillée
La Figure 1 illustre l’architecture d’un système de services pour terminaux de paiement selon un exemple de réalisation de l’invention.
Le système comprend une plateforme de service 103. Cette plateforme de service comprend un premier module d’exécution 105 qui permet l’opération des services de paiement à un terminal de paiement 101 . La plateforme de service 103 comprend également un module de programmation des services de paiement 104 auquel un utilisateur, c’est-à-dire une personne opérant un terminal de paiement 101 peut se connecter depuis un dispositif de traitement de l’information 102. Ce dispositif peut typiquement être constitué d’un ordinateur personnel, d’une tablette, ou de tout terminal pouvant se connecter à un réseau de communication de données du type Internet. Le dispositif de traitement de l’information dispose typiquement d’un client Internet, tel qu’un navigateur web, permettant à l’utilisateur d’interagir avec le module de programmation des services de paiement 104.
La plateforme de service 103 est décrite ici de manière logique. Elle peut être constituée d’un ou de plusieurs serveurs interagissant pour fournir le service décrit. De même, seuls les aspects essentiels à la définition puis à l’exécution des applications de service de paiement sont décrites. La plateforme comprend également des services annexes comme, par exemple, l’authentification et la gestion des utilisateurs qui ne sont pas décrits en détail.
Le module de programmation des services de paiement 104 permet à l’utilisateur de programmer de façon simple, intuitive et rapide, un service de paiement sur la base de services de base offerts par la plateforme de service 103. Selon un exemple de réalisation de l’invention, le module de programmation des services de paiement offre une programmation graphique par agencement de services élémentaires, leur connexion et la définition de leurs paramètres. Ainsi, un utilisateur peut facilement concevoir une application complète pour un terminal de paiement. Cette application complète, une fois définie, est constituée de deux modules logiciels destinés l’un à s’exécuter sur le terminal de paiement 101 et l’autre sur le module d’exécution 105. Les deux modules logiciels interagissent alors pour exécuter ensemble l’application. Dans certains modes de réalisation, l’application implique plus de deux modules logiciels s’exécutant sur différents dispositifs informatiques et interagissant entre eux.
Au moins certains des services élémentaires constituant l’application pour terminal de paiement peuvent faire appel à un ou plusieurs services externes 106 à 109. Ces services externes comprennent par exemple des fournisseurs de services de paiement (PSP pour Payment Service Provider en anglais), des services de courrier électronique, des services de messagerie par message texte court (SMS pour Short Message Service en anglais), des services de collecte et d’analyse d’avis clients, des services d’animation commerciale (programme de fidélité, de gestion de coupons...), des services d’identification du client (ex : gestion de tokens) ou autres.
Ainsi, un utilisateur opérant un terminal de paiement peut utiliser la plateforme pour définir une application complète pour terminal de paiement. Cette définition ne nécessite pas de connaissance particulière en programmation, elle est rapide et aisée à utiliser. Une fois l’application définie, la plateforme génère tous les modules logiciels devant s’exécuter sur le terminal de paiement. La plateforme génère également un second module logiciel qui s’exécute sur la plateforme elle- même. Les modules logiciels destinés au terminal de paiement ou, de manière plus générale, tout dispositif informatique, sont déployés sur ceuxci. Lors de l’utilisation du terminal de paiement, le module logiciel déployé sur le terminal s’exécute, se connecte à la plateforme et coopère avec le module logiciel s’exécutant sur la plateforme pour fournir les services composant l’application. Certains de ses services peuvent utiliser des services externes qui interagissent avec la plateforme de service.
L’utilisateur peut donc, à tout moment, définir ou modifier son application de paiement pour s’adapter à l’évolution de ses besoins et offrir le niveau de service souhaité à ses clients. De nouveaux services apparaissant sur le marché peuvent être offerts rapidement par intégration à la plateforme de service. Dès cette intégration faite, les utilisateurs peuvent les intégrer à leur application pour terminal de paiement.
La Figure 2 illustre un exemple d’interface de programmation des applications de services pour terminaux de paiement.
L’application de programmation graphique permettant la programmation des applications de service fonctionne sur un mode client-serveur entre le client 102 utilisé par l’utilisateur et le module de programmation 104 sur la plateforme de service. L’exemple ici décrit est basé sur l’utilisation d’un navigateur web standard sur le client 102 interagissant avec un module de programmation 104 développé sous la forme d’un service web sur la plateforme. Toute autre implémentation est bien sûr envisageable comme un client natif interagissant avec une application native côté serveur par exemple.
Dans cet exemple, l’interface de programmation comprend une fenêtre principale
201 qui comprend deux sous-fenêtres.
Une première sous-fenêtre 202 comprend une liste des services élémentaires 203 disponibles. Avantageusement cette liste peut être ordonnée par type de services. Avantageusement, la liste peut être hiérarchisée et permettre de n’afficher que les services d’une même catégorie à un instant donné pour faciliter l’identification du service recherché, si le nombre total de services est grand. Une seconde sous-fenêtre 204 permet l’édition de l’application de service pour terminaux de paiement. Dans cette fenêtre d’édition 204, l’utilisateur peut agencer des services 205 sélectionnés dans la liste des services 202. Typiquement, l’utilisateur peut sélectionner un service dans la liste des services
202 et le glisser-déposer dans la fenêtre d’édition 204. Le service 205, une fois déposé dans la fenêtre d’édition expose au moins un point d’entrée et au moins un point de sortie, ainsi que d’éventuels points de branchement ( hooks en anglais). L’utilisateur peut alors connectés les points d’entrée et de sortie des différents services pour constituer son application. Les services 205 exposent également, si nécessaire, un ensemble de paramètres permettant à l’utilisateur de personnaliser le service selon ses besoins.
L’interface comprend également, non représenté sur la figure, les contrôles permettant la sauvegarde d’une application ainsi que la génération et le déploiement des modules logiciels générés sur le terminal de paiement et sur la plateforme. Avantageusement, le déploiement du module logiciel destiné au terminal de paiement peut être fait sur un ensemble de terminaux de paiement, par exemple dans le cas d’un magasin comportant un ensemble de terminaux de paiement ou dans le cas d’une chaîne de magasins.
La Figure 3 illustre un service 301 tel qu’il apparait dans la fenêtre d’édition 204 selon un exemple de réalisation de l’invention.
Le service comprend au moins un point d’entrée 304 et au moins un point de sortie 305. Selon le service, plusieurs points de sortie (ex : point de sortie n°1 = transaction validée, point de sortie n°2 = transaction en erreur, point de sortie n°3 = transaction annulée par le client) peuvent être présents. Ce sont ces points d’entrée et de sortie qui permettent de connecter les différents services entre eux pour constituer l’application. Cette connexion est avantageusement faite en tirant une connexion entre deux points à la souris.
Un ou plusieurs points de branchement 306 peuvent être présents. Ces points de branchement permettent d’interrompre le déroulement du service à un moment donné pour déclencher le déroulement d’un ou de plusieurs autres services connectés à ce point de branchement. Lorsque ces services se terminent, le service interrompu est repris.
Dans l’exemple de réalisation, le service comprend une zone d’identification 302. Cette zone d’identification peut comprendre le nom du service, un identifiant du service ainsi qu’une description longue du service. Avantageusement, un bouton dans cette zone permet d’ouvrir une page d’aide qui donne des détails sur le fonctionnement du service à l’utilisateur.
Une zone de paramétrage du service 303 est présente si le service peut être paramétré. Cette zone de paramétrage comprend typiquement des contrôles, comme des menus déroulants, des cases à cocher à sélection multiple ou exclusive, des champs numériques ou textuels etc... L’utilisateur peut alors facilement paramétrer chaque service en fonction de ses besoins.
Par exemple, un service de paiement pourra permettre à l’utilisateur de choisir le type de carte acceptée parmi les cartes à puce avec contact, sans contact, les cartes magnétiques et saisie manuelle, etc. Il peut également permettre de choisir les solutions acceptées parmi, par exemple, les solutions VISA, MasterCard, American Express, Discover, JCB.... Les types de paiement acceptés peuvent également être paramétrés parmi différents types (exemple : débit, crédit, remboursement...). Des paramètres par défaut peuvent également être paramétrés. Des points de branchement peuvent être offerts pour permettre d’insérer des services autres à certains moments de l’exécution d’un service (e.g. le paiement) paiement comme, par exemple, avant l’insertion de la carte, après l’insertion de la carte, avant la sélection de l’application et après la sélection de l’autorisation.
Par exemple, si l’utilisateur souhaite apporter la possibilité à ses clients de payer en utilisant leur propre devise en lieu et place de la devise par défaut de l’utilisateur, un service de conversion de devise peut être branché sur le point de branchement intervenant après l’insertion de la carte. Ainsi, après l’insertion de la carte, le client se verra proposer la sélection d’une devise, par exemple le dollar américain, au lieu de la devise par défaut du commerçant, par exemple l’euro. Le client peut alors lire sur le terminal le montant net qui lui sera prélevé sur son compte bancaire dans sa devise et incluant les frais éventuels comme le taux de change et la commission de change.
La Figure 4 illustre le déploiement de l’application de service selon un mode de réalisation de l’invention.
Une fois l’application de service 401 définie par l’utilisateur en utilisant le module de programmation 104 à l’aide de l’interface 201 , plusieurs modules logiciels tels que 402 et 403 sont générés. Le module logiciel 402 est destiné à s’exécuter sur le terminal de paiement 404 (ou autre dispositif informatique) sous le contrôle d’un orchestre de service 406. Le module logiciel 403 est destiné à s’exécuter sur le serveur (ou autre dispositif informatique) au sein du module d’exécution des service 405, correspondant au module illustré dans la Figure 1 sous la référence 105. Le module logiciel 403 s’exécute sous le contrôle d’un orchestre de service 407.
Dans un mode de réalisation, les modules logiciel 402 et 403 sont composés d’un ensemble de ressources comprenant des scripts, des fichiers (ex : images, fichier de configuration...), et d’un flux de travail ( workflow en anglais) qui définit l’ordonnancement des services. Chaque script est paramétré en fonction des paramètres définis par l’utilisateur. Chaque service utilisé se traduit donc par un premier script s’exécutant sur le terminal de paiement (ou autre dispositif informatique) et un second script s’exécutant sur la plateforme (ou autre dispositif informatique). Au moins un dispositif informatique est obligatoire. Ces scripts coopèrent au travers de la connexion 408 entre les dispositifs informatiques. Le script peut également coopérer avec des services externes comme expliqué en rapport avec la Figure 1 . Ainsi, l’utilisateur du terminal de paiement utilise une application qui lui semble exécutée sur ledit terminal mais qui met en œuvre finalement des modules logiciels locaux au terminal, d’autres sur la plateforme de service et potentiellement des services externes.
Les orchestres de service 406 et 407, s’exécutant respectivement sur les dispositifs informatiques, sont en charge de l’exécution des différents scripts composant les différents services en accord avec le flux de travail défini. Ces orchestres de service, exécutent également les scripts avec les paramètres correspondant à la programmation de l’application faite dans le module de programmation 104.
Les scripts qui s’exécutent sur les dispositifs informatiques peuvent être programmés dans le même langage de script où alors dans des langages différents selon les modes de réalisations de l’invention. Ce choix dépend des choix logiciels, en termes de système d’exploitation et d’environnement logiciel faits pour le terminal de paiement et pour la plateforme. Ces langages de script comprennent, par exemple, Javascript, Lua, Python, Kotlin, Groovy ou autres. Dans certains modes de réalisation, de véritables exécutables peuvent être compilés en lieu et place des scripts.
La Figure 5 illustre le déroulement d’un service, ici le service de paiement, selon un exemple de réalisation de l’invention.
Le terminal initie l’exécution du service par le bloc de traitement 501 . Lors de ce traitement, il est d’abord vérifié que le montant et la devise sont fournis au démarrage du service et que les valeurs sont correctes. Par exemple, le montant doit être supérieur à un euro et la devise doit être l’euro. Ensuite, le bloc de traitement 501 demande l’insertion de la carte au client. La carte est alors lue et la devise par défaut de la carte est extraite. Si un service externe est connecté au point de branchement « après insertion de la carte », alors ce service est déclenché. Le code PIN du client est ensuite vérifié. En cas de succès de la vérification du code PIN du client, une requête en autorisation 502 est transmise au script correspondant qui s’exécute sur la plateforme.
Ce script s’exécutant sur la plateforme effectue un bloc de traitement 503. Ce bloc de traitement se charge de sélectionner la banque devant traiter le paiement. Pour ce faire, le script s’exécutant sur la plateforme doit faire appel à d’autres services disponibles sur cette plateforme. Par exemple, la plateforme comporte une base de données contenant la référence des banques avec lesquelles le commerçant a signé un contrat d’acquisition. Cette base de données contient également les informations techniques de connexion aux banques, telles que les adresses IP principale et secondaire et les identifiants de connexion. Avantageusement, les contrats d’acquisition peuvent être modélisés afin de pouvoir évaluer quelle banque est la plus compétitive pour un type de transaction donné. Par exemple, un paiement international « VISA» peut être moins cher auprès d’une banque alors qu’un paiement « MasterCard » sera moins cher auprès d’une autre banque.
En fonction de toutes ces informations, le module de traitement 503 choisit une banque et lui transmets la requête en paiement 504. La banque choisie, traite alors la requête lors d’un traitement 505. A l’issue de ce traitement, le paiement est validé ou refusé. La banque transmet ce résultat lors d’une réponse 506 à destination de la plateforme. La plateforme, lors d’un traitement 507 retransmet la réponse 508 au terminal de paiement.
La Figure 6 illustre les principales étapes de l’exécution d’une application de service dans un mode de réalisation de l’invention.
Dans une étape 601 , une transaction est lancée.
Dans une étape 602, l’orchestre de services du terminal de paiement lance le premier script composant l’application. L’orchestre de services de terminal est en charge du lancement successif des services au fur et à mesure de leur exécution sur le terminal de paiement ou le dispositif informatique.
Lors d’une étape 603, l’application s’exécute. Lors d’une étape 604, lorsqu’un des services nécessite une connexion à la plateforme, cette connexion est initiée par le service. Pour ce faire, une authentification forte oeut être utilisée pour authentifier le terminal de paiement auprès de la plateforme. Avantageusement, cette authentification utilise un système cryptographique (ex : clés asymétriques) géré au sein d’un module matériel sécurisé. Ce module matériel sécurisé est composé d’une partie physique et d’une partie logicielle dont le rôle est de protéger les clés et les opérations cryptographiques. Toute tentative d’intrusion logique ou physique d’un module matériel sécurisé peut mener à l’effacement immédiat des clés cryptographiques qu’il contient. Un tel module matériel sécurisé est fonctionnellement très proche d’une carte à puce tout en disposant d’une capacité de traitement plus importante.
Lors de l’étape 605, le contexte applicatif, c’est-à-dire, typiquement, la liste des données capturées et/ou générées par l’application, est transférée au serveur. Lors de l’étape 607, l’orchestre de services de la plateforme identifie le script serveur correspondant à l’application de service sur la base de l’identification du terminal de paiement et le lance avec les paramètres associés.
Lors de l’étape 608, l’application s’exécute par orchestration des différents scripts de service sur le terminal de paiement et sur la plateforme. Au besoin, les scripts s’exécutant sur la plateforme font appel aux services externes comme décrit en relation avec la Figure 5.
Lors de l’étape 609, symétrique de l’étape 604, une connexion au client est initiée par le serveur.
Lors de l’étape 610, symétrique de l’étape 605, le contexte applicatif serveur est transféré au client.
Les étapes 602 à 610 peuvent s’exécuter un nombre quelconque de fois en fonction des besoins de l’application.
Lors de l’étape 606, à la fin de l’application, le script client initie la fin d’exécution. La plateforme est notifiée de la fin d’exécution et peut alors libérer les ressources utilisées par le script sur la plateforme.
Dans un mode de réalisation, un même orchestre de services est déployé sur le client et le, ou les, serveur. L’application est alors vue comme un ensemble d’un ou plusieurs modules logiciels s’exécutant sur un ou plusieurs dispositifs informatiques et collaborant entre eux en fonction des besoins de l’application. Le passage du contrôle d’un dispositif à l’autre se fait comme illustré par la figure 6 entre le client et le serveur. La transaction peut alors être initiée indifféremment par l’un ou l’autre de ces modules logiciels.
Dans un premier exemple, une enseigne de magasin pourrait déployer une instance de l’orchestre de services sur chacun des terminaux de paiement, une instance de l’orchestre de service sur un serveur au sein de chaque magasin et une instance sur un serveur central distant. L’application serait alors constituée de l’ensemble des modules logiciels exécutés sur chacune de ces instances de l’orchestre de services.
Dans un second exemple, une instance de l’orchestre de service serait déployée sur chaque terminal de paiement, un seul de ces terminaux serait connecté à internet. L’instance déployée sur le terminal de paiement connecté à internet agirait alors en proxy pour les autres instances. Plusieurs terminaux collaborent alors à la réalisation de la transaction.
Dans un troisième exemple, un magasin dispose d’un écran doté d’un moyen de lecture NFC, d’un terminal de paiement disposant de tous les moyens de valider un paiement qui communique avec un serveur distant. Ces trois dispositifs sont dotés d’une instance de l’orchestre de services et collaborent pour réaliser la transaction.
La Figure 7 illustre l’architecture logicielle du terminal de paiement dans un exemple de réalisation de l’invention.
Dans l’exemple de réalisation de l’invention ici décrit, le terminal de paiement fonctionne sous le contrôle du système d’exploitation Android de Google (marques déposée). Ce système d’exploitation 700 permet de faire fonctionner un ensemble de modules logiciels nécessaires au fonctionnement des applications de service selon l’exemple de réalisation de l’invention. Ces modules sont implémentés sous la forme d’une ou plusieurs applications Android selon les modes de réalisation.
Le module central est l’orchestre de services 704. C’est ce module qui charge les différents scripts constituant l’application de service, qui permet de les exécuter et de les ordonnancer. Pour ce faire, l’orchestre de services 704 comporte un moteur d’exécution du langage de script choisi :
• Le terminal est amené à traiter des scripts qu’il est le seul à pouvoir exécuter car ils font appel à des ressources uniquement disponibles dans le terminal (ex : communication avec le lecteur de carte à puce).
• A l’inverse, d’autres scripts ne peuvent être exécutés que par le serveur (ex : connexion à un service tiers hébergé à l’extérieur de l’environnement du serveur et non accessible par le terminal.
• Dans certains cas, certains scripts peuvent s’exécuter indifféremment sur le terminal ou le serveur.
Une transaction se compose donc de 3 éléments majeurs :
- Un workflow qui décrit l’enchaînement des scripts et leur portée (i.e. exécution exclusive par le terminal, le serveur ou indifférenciée)
- Un ensemble de scripts (clients et serveur)
- Un « contexte » contenant l’ensemble des données capturées ou générées pendant une transaction.
Les scripts sont disponibles dans les 2 environnements (i.e. terminal et serveur) avant le démarrage d’une transaction afin de réduire le délai de démarrage de la transaction. Cependant, il est aussi possible que le terminal télécharge les scripts et le « workflow » au démarrage d’une transaction.
L’orchestre de services est responsable du transfert du contexte du terminal vers le serveur (et vice versa) lors du « passage de relais ». Les applications de service partagent un certain nombre de fonctionnalités communes mises à disposition soit par le terminal, soit par le serveur. Elles doivent toutes accéder au lecteur de carte de paiement intégré au terminal, communiquer avec la plateforme de service, gérer l’interface du terminal ou encore gérer des opérations de cryptographie dans le cadre de leur authentification auprès de la plateforme par exemple. Ces fonctionnalités communes sont fournies par un ensemble de modules logiciels typiquement rassemblés en une ou plusieurs applications Android, ou services « serveur ». Un module d’interface homme machine (IHM) 702 offre les fonctions de gestion de l’écran du terminal de paiement ainsi que du clavier. Ce module permet les interactions avec le client utilisateur du terminal.
Un module de sécurité 705 gère les opérations de cryptographie liées au fonctionnement des services. Ces opérations comprennent les authentifications auprès de la plateforme et si nécessaire auprès de services tiers. Ce module de sécurité peut interagir avec un microcontrôleur sécurisé 708 présent dans le terminal et agissant comme un élément de sécurité ( secure element e n anglais), c’est-à-dire un composant matériel chargé des opérations cryptographiques proprement dites et du stockage des clés, ce composant étant dotés de fonctionnalités de sécurité visant à le rendre inviolable.
Le module d’intégration lecteur de carte 703 offre les interactions avec le ou les lecteurs de carte présents dans le terminal de paiement. Ces lecteurs peuvent être filaires ou sans fil.
Le module d’interface plateforme 706 offre les communications avec la plateforme. C’est typiquement le module qui va permettre à un script client de communiquer avec le script serveur correspondant et via ce script serveur avec d’éventuels services tiers.
Un module de mise-à-jour 701 permet de mettre les workflows, les scripts et les différents modules à jour lorsque de nouvelles versions sont disponibles.
Un module de communication 707 gère les communications entre ces différents modules et l’extérieur du terminal de paiement et notamment le lecteur de carte et la plateforme de service. C’est ce module qui établit les tunnels de communication sécurisé, par exemple avec la plateforme.
La Figure 8 illustre l’architecture logicielle de la plateforme serveur dans un exemple de réalisation de l’invention. Cette figure n’illustre pas le module de programmation 104 mais uniquement l’architecture utile à l’exécution des applications de service.
Le cœur 800 de la plateforme est constitué d’un ensemble de modules. Ces modules centraux comprennent l’orchestre de service 803 qui gère le chargement, l’exécution et l’ordonnancement des scripts serveur de l’application de service. C’est le pendant côté serveur de l’orchestre de service 704 sur le terminal.
De manière similaire à l’architecture du terminal, les scripts s’exécutant sur la plateforme peuvent utiliser un ensemble de services à leur disposition sous la forme de modules logiciels accessibles.
Ces services comprennent un module d’authentification 801 qui gère les authentifications. Ce module coopère typiquement avec un module matériel sécurisé 809 ( HSM pour Hardware Secure Module en anglais). Ce module d’authentification va gérer les opérations cryptographiques pour le compte de tous les modules qui le nécessitent.
Les modules 801 et 802 permettent sont le point d’accès au module 809. Ils se chargent de préparer et optimiser les opérations déléguées au module 809 (ex : conversion des données du format XML ou JSON en un format unique binaire adapté au HSM).
Un module 804 de surveillance, permet de surveiller l’exécution des scripts et l’utilisation des différents modules et des scripts en cours d’exécution pour détecter de possibles anomalies pouvant provenir de dysfonctionnements ou d’éventuelles attaques de la plateforme.
D’autres modules sont également présents, non représentés, comme par exemple un module d’enregistrement des opérations techniques et métiers effectuées ( log en anglais), un module éventuel de traduction de protocole si nécessaire pour interagir avec certains services tiers, un module de mise à jour des composants logiciels. Cette liste n’est pas exhaustive.
Ces services s’appuient également sur une base de données 808 qui contient, entre autres :
- Les caractéristiques des services tiers (adresse IP, token d’authentification...)
- Les configurations de chaque banque autorisée pour chaque terminal (ex : numéro du contrat commerçant, devises autorisées, montants plafonds...)
- La liste des services autorisés pour chaque terminal
- Le workflow actif (et les scripts associés) pour chaque terminal
- Etc. La plateforme coopère dans son fonctionnement avec des entités externes. Elle est donc dotée de services gérant la communication avec ces entités externes. Un module 805 gère les communications de la plateforme avec les commerçants. C’est ce module qui gère la communication avec les terminaux de paiement 810 dans le cadre de l’exécution des applications de service. C’est aussi ce module qui gère l’administration par un commerçant de son service à partir d’un terminal d’administration 81 1 .
Un module 806 gère les communications de la plateforme avec les services tiers. Ces services sont typiquement sollicités par les scripts exécutés par le service d’orchestration de la plateforme lors de l’exécution des applications de service. On peut citer parmi ces services tiers, un service 812 de gestion des courriers électroniques, des services bancaires 813 comme les services de paiement, les services électroniques marchands. Parmi ces services, on trouve aussi des services tel que l’extranet 814 d’un commerçant. En effet, certaines applications de services peuvent nécessiter des données propres au commerçant, par exemple pour appliquer des règles telles que l’attribution d’une promotion selon des critères propres au commerçant, ou encore la proposition d’un questionnaire aux clients ayant dépensés au moins 100 euros dans le mois.
La plateforme comporte également un module 807 qui donne un accès au gérant de la plateforme pour son administration.
Dans l’exemple de réalisation, ces différents modules sont implémentés sous la forme de services dans une architecture orientée service ( SOA pour Service Oriented Architecture en anglais). Tous ces services communiquent, par exemple, par le biais d’un service de messages ( message broker en anglais). Dans un exemple de réalisation, le système d’exploitation est Linux, l’hyperviseur gérant la virtualisation des serveurs est Proxmox en développement et VMWare en production, les services sont gérés par Kubernetes/Docker, le service de messages est ActiveMQ, les services sont développés en Java/Spring, Node.js et/ou C/C++, la base de données peut être Cassandra, MongoDB ou ElasticSearch.
Ainsi, le système proposé permet à un commerçant de définir rapidement une application de service (aussi appelé « workflow ») pour ses terminaux de paiement, de la déployer sans délai. Ensuite, cette application peut être modifiée à tout moment. De nouveaux services apparaissant sur le marché peuvent être intégrés à la plateforme et rendu disponibles aux commerçants qui peuvent alors l’intégrer à leur application de paiement. Tout ceci peut être fait sans devoir supporter les coûts est les délais afférents aux développements d’applications de service propriétaires.
La figure 9 est un bloc-diagramme schématique d'un dispositif de traitement de l’information 900 pour la mise en œuvre d'un ou plusieurs modes de réalisation de l'invention. Le dispositif 900 de traitement de l’information peut être un périphérique tel qu'un micro-ordinateur, un poste de travail ou un terminal mobile de télécommunication. Le dispositif 900 comporte un bus de communication connecté à :
- une unité centrale de traitement 901 , tel qu'un microprocesseur, notée CPU ;
- une mémoire à accès aléatoire 902, notée RAM, pour mémoriser le code exécutable du procédé de réalisation de l'invention ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en œuvre du procédé selon des modes de réalisation de l'invention ; la capacité de mémoire du dispositif peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple ;
- une mémoire morte 903, notée ROM, pour stocker des programmes informatiques pour la mise en œuvre des modes de réalisation de l'invention ;
- une interface réseau 904 est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmis ou reçus. L'interface réseau 904 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil). Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur 901 ;
- une interface utilisateur 905 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur ;
- un dispositif de stockage 906 tel que décrit dans l’invention et noté HD ; - un module d’entrée/sortie 907 pour la réception / l'envoi de données depuis / vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.
Le code exécutable peut être stocké dans une mémoire morte 903, sur le dispositif de stockage 906 ou sur un support amovible numérique tel que par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 904, afin d'être stocké dans l'un des moyens de stockage du dispositif de communication 900, tel que le dispositif de stockage 906, avant d'être exécuté. L'unité centrale de traitement 901 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation de l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités. Après la mise sous tension, le CPU 901 est capable d'exécuter des instructions de la mémoire RAM principale 902, relatives à une application logicielle. Un tel logiciel, lorsqu'il est exécuté par le processeur 901 , provoque l’exécution des procédés décrits.
Dans ce mode de réalisation, l'appareil est un appareil programmable qui utilise un logiciel pour mettre en œuvre l'invention. Toutefois, à titre subsidiaire, la présente invention peut être mise en œuvre dans le matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l’invention pourra appliquer des modifications dans la description précédente.
Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n'est pas limitée aux modes de réalisation spécifiques, et les modifications qui se trouvent dans le champ d'application de la présente invention seront évidentes pour une personne versée dans l'art.

Claims

Revendications
1 . Plateforme de service pour terminaux de paiement caractérisée en ce qu’elle comprend :
- des moyens (104) de programmation graphique d’une application de service à partir d’un ensemble de services élémentaires accessibles depuis un terminal distant ;
- des moyens de générer à partir d’une application de service, un module logiciel client destiné à s’exécuter sur un terminal de paiement et un module logiciel serveur destiné à s’exécuter sur la plateforme de service ;
- des moyens de transmission du module logiciel client sur le terminal de paiement ; et
- des moyens d’exécuter le module logiciel serveur, le module logiciel serveur lorsqu’il est exécuté coopérant avec le module logiciel client exécuter sur le terminal de paiement pour réaliser l’application de service.
2. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce que le module logiciel client est composé d’un ensemble d’au moins un script client.
3. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce que :
- le module logiciel serveur est composé d’un ensemble d’au moins un script serveur ; et
- elle comporte un module orchestre de service pour ordonnancer et exécuter l’ensemble des scripts serveur.
4. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce qu’elle comprend en outre des moyens (806) de communiquer avec des services externes accessible depuis le module logiciel serveur.
5. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce qu’elle comprend en outre des moyens (807) d’administration de la plateforme de service.
6. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce qu’elle comprend en outre un module (805) de gestion des communications avec le terminal de paiement et le terminal distant.
7. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce qu’elle comprend en outre un module matériel sécurisé (809).
8. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce qu’elle comprend en outre une base de données (808).
9. Plateforme de service pour terminaux de paiement selon la revendication 1 , caractérisée en ce que les moyens de programmation graphique comprennent une liste de services élémentaires pouvant être sélectionnés.
10. Plateforme de service pour terminaux de paiement selon la revendication 9, caractérisée en ce que chaque service élémentaire est représenté par un objet graphique comportant au moins une entrée et au moins une sortie, une sortie d’un objet graphique pouvant être connectée à une entrée d’un autre objet graphique.
1 1 . Plateforme de service pour terminaux de paiement selon la revendication 10, caractérisée en ce que au moins un objet graphique comprend en outre un point de branchement, le point de branchement pouvant être connecté à une entrée d’un autre objet graphique et une sortie d’un autre objet graphique pouvant être connecté au point de branchement.
12. Plateforme de service pour terminaux de paiement selon la revendication 10, caractérisée en ce qu’au moins un objet graphique comporte au moins un contrôle permettant de définir un paramètre du service élémentaire représenté.
13. Terminal de paiement caractérisé en ce qu’il comprend :
- des moyens de connexion à une plateforme de service pour terminaux de paiement selon l’une des revendications 1 à 12 ; et
- des moyens d’exécuter un module logiciel client transmis par la
plateforme.
14. Terminal de paiement selon la revendication 13, caractérisée en ce que le module logiciel client est composé d’un ensemble d’au moins un script client.
15. Terminal de paiement selon la revendication 14, caractérisée en ce qu’il comporte un module orchestre de service pour ordonnancer et exécuter l’ensemble des scripts client.
16. Système d’application de service pour terminaux de paiement caractérisé en ce qu’il comporte :
- une plateforme de service pour terminaux de paiement selon l’une des revendications 1 à 12 ; et
- au moins un terminal de paiement selon l’une des revendications 13 à 15.
17. Procédé d’exécution d’une application de service au sein d’un système d’application de service pour terminaux de paiement selon la revendication 16, caractérisé en ce qu’il comprend :
- une étape de lancement d’un module logiciel client par le terminal de paiement ;
- une étape de connexion du terminal de paiement à la plateforme de service pour terminaux de paiement ;
- une étape de lancement d’un module logiciel serveur sur la plateforme de service pour terminaux de paiement ;
- une étape d’exécution du module logiciel client et du module logiciel serveur, le module logiciel client et le module logiciel serveur coopérant pour réaliser l’application de service.
18. Procédé selon la revendication 17, caractérisé en ce qu’il comporte en outre une étape de terminaison de l’application par le module logiciel client.
19. Procédé selon la revendication 17, caractérisé en ce qu’il comporte en outre une étape de coopération du module logiciel serveur avec au moins un service externe à la plateforme de service pour terminaux de paiement.
PCT/FR2020/051051 2019-06-21 2020-06-17 Système d'applications de service pour terminaux de paiement WO2020254761A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP20785770.7A EP3987390A1 (fr) 2019-06-21 2020-06-17 Système d'applications de service pour terminaux de paiement
AU2020296966A AU2020296966A1 (en) 2019-06-21 2020-06-17 Service application system for payment terminals
CA3143068A CA3143068A1 (fr) 2019-06-21 2020-06-17 Systeme d'applications de service pour terminaux de paiement
US17/621,337 US20220366393A1 (en) 2019-06-21 2020-06-17 Service application system for payment terminals
BR112021025579A BR112021025579A2 (pt) 2019-06-21 2020-06-17 Sistema de aplicações de serviço para terminal de pagamento

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1906735 2019-06-21
FR1906735A FR3097672A1 (fr) 2019-06-21 2019-06-21 Système d’applications de service pour terminaux de paiement

Publications (1)

Publication Number Publication Date
WO2020254761A1 true WO2020254761A1 (fr) 2020-12-24

Family

ID=68501710

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2020/051051 WO2020254761A1 (fr) 2019-06-21 2020-06-17 Système d'applications de service pour terminaux de paiement

Country Status (7)

Country Link
US (1) US20220366393A1 (fr)
EP (1) EP3987390A1 (fr)
AU (1) AU2020296966A1 (fr)
BR (1) BR112021025579A2 (fr)
CA (1) CA3143068A1 (fr)
FR (1) FR3097672A1 (fr)
WO (1) WO2020254761A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11762702B1 (en) 2022-04-20 2023-09-19 Snowflake Inc. Resilience testing using a declarative engine for workloads (DEW)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100228683A1 (en) * 2009-03-06 2010-09-09 TxVia, Inc. Issuing systems, acquiring systems, and payment networks/systems development
WO2013056104A1 (fr) * 2011-10-12 2013-04-18 C-Sam, Inc. Plateforme mobile d'activation de transaction sécurisée à plusieurs étages
US20150339107A1 (en) * 2014-05-22 2015-11-26 Oracle International Corporation Generating runtime components
US20160378439A1 (en) * 2015-06-29 2016-12-29 Oracle International Corporation Cloud based editor for generation of interpreted artifacts for mobile runtime

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716096B2 (en) * 1996-11-27 2010-05-11 Diebold Self-Service Systems A Division Of Diebold, Incorporated Application service provider and automated transaction machine system and method
JP3489962B2 (ja) * 1997-04-23 2004-01-26 沖電気工業株式会社 プログラム開発装置および並列リアルタイム処理装置
US6173438B1 (en) * 1997-08-18 2001-01-09 National Instruments Corporation Embedded graphical programming system
US6243092B1 (en) * 1997-12-02 2001-06-05 Aspect Communications Transaction flow editing tool
US6808111B2 (en) * 1998-08-06 2004-10-26 Visa International Service Association Terminal software architecture for use with smart cards
FR2806493A1 (fr) * 2000-03-14 2001-09-21 Cryo Networks Procede pour la programmation graphique
DE60015810T2 (de) * 2000-04-11 2005-10-27 Visa International Service Association, Foster City Integriertes verfahren zur herstellung von chipkarten
US20020032655A1 (en) * 2000-09-14 2002-03-14 Thierry Antonin System and method for providing financial services terminals with a document driven interface
US7047518B2 (en) * 2000-10-04 2006-05-16 Bea Systems, Inc. System for software application development and modeling
US6889375B1 (en) * 2000-11-17 2005-05-03 Cisco Technology, Inc. Method and system for application development
US20030037310A1 (en) * 2001-08-18 2003-02-20 David Ge Visual programming tool and execution environment for developing computer software applications
US20050177816A1 (en) * 2002-03-08 2005-08-11 National Instruments Corporation Automatic generation of graphical program code for a graphical program based on the target platform of the graphical program
KR100742022B1 (ko) * 2002-10-24 2007-07-23 엘지카드 주식회사 개방형 스마트 카드(또는 아이씨 카드)의 후발급 애플리케이션 제작방법
WO2004095352A1 (fr) * 2003-04-22 2004-11-04 Visa International Service Association Mise a niveau de carte a puce pour terminaux a carte a pistes magnetiques existantes
WO2006017496A2 (fr) * 2004-08-03 2006-02-16 Ebay Inc. Procede et systeme de conception d'un processus de reglement de differends
US7565640B2 (en) * 2004-10-01 2009-07-21 Microsoft Corporation Framework for seamlessly authoring and editing workflows at design and runtime
US7613671B2 (en) * 2005-02-15 2009-11-03 Fair Isaac Corporation Approach for re-using business rules
US20060218228A1 (en) * 2005-03-24 2006-09-28 Security First Technologies Corp Client platform architecture
US20060218061A1 (en) * 2005-03-25 2006-09-28 Security First Technologies Corp. Integrated financial services platform
US20070061777A1 (en) * 2005-09-09 2007-03-15 Source Technologies, Llc System, method, and computer program product for graphically generating a program for controlling the operation of a kiosk
GB0519519D0 (en) * 2005-09-24 2005-11-02 Eastman Kodak Co Payment terminals
US10032160B2 (en) * 2005-10-06 2018-07-24 Mastercard Mobile Transactions Solutions, Inc. Isolating distinct service provider widgets within a wallet container
US8589868B2 (en) * 2005-12-22 2013-11-19 Ncr Corporation Creating a terminal application
US7658323B2 (en) * 2006-05-24 2010-02-09 Sun Microsystems, Inc. Point-of-service (POS) and POS application compatability
US20080028057A1 (en) * 2006-07-26 2008-01-31 International Business Machines Corporation System and method to facilitate design and operation of event-driven, embedded solutions
KR101341116B1 (ko) * 2007-01-09 2013-12-11 온 트랙 이노베이션스 엘티디. 스마트 카드 장치를 일괄 테스트하기 위한 방법 및 장치
US8341595B2 (en) * 2007-05-30 2012-12-25 Roam Data Inc System and method for developing rich internet applications for remote computing devices
US20090119640A1 (en) * 2007-11-07 2009-05-07 Microsoft Corporation Graphical application for building distributed applications
US20090132690A1 (en) * 2007-11-20 2009-05-21 Retail Information Systems Pty Ltd On-Demand Download Network
MX2011003043A (es) * 2008-09-22 2011-05-25 Visa Int Service Ass Manejo de aplicacion de pago en el aire instalado en dispositivo movil.
US20100145854A1 (en) * 2008-12-08 2010-06-10 Motorola, Inc. System and method to enable a secure environment for trusted and untrusted processes to share the same hardware
US8386288B2 (en) * 2009-01-27 2013-02-26 Direct Response Medicine, Llc Workflow management system and method with workflow package exchange between drop-box application programs
US10454693B2 (en) * 2009-09-30 2019-10-22 Visa International Service Association Mobile payment application architecture
GB2481191A (en) * 2010-02-25 2011-12-21 Sita Information Networking Computing Ireland Ltd Graphical development tool for software application development
US8744820B2 (en) * 2011-02-24 2014-06-03 Verizon Patent And Licensing Inc. Integration of workflows from various systems
US10223674B2 (en) * 2011-05-11 2019-03-05 Riavera Corp. Customized transaction flow for multiple transaction types using encoded image representation of transaction information
US20120291006A1 (en) * 2011-05-12 2012-11-15 Google Inc. Development Architecture for Cloud-Based Applications
US8412631B2 (en) * 2011-05-13 2013-04-02 American Express Travel Related Services Company, Inc. Cloud enabled payment processing system and method
EP2751682A4 (fr) * 2011-08-29 2015-01-07 Fiberlink Comm Corp Plateforme permettant le déploiement et la distribution de modules jusqu'à des extrémités
US20130246345A1 (en) * 2011-09-13 2013-09-19 Wappwolf, Inc. Systems and methods for online workflow implementation
US8904239B2 (en) * 2012-02-17 2014-12-02 American Express Travel Related Services Company, Inc. System and method for automated test configuration and evaluation
CA3126471A1 (fr) * 2012-10-17 2014-04-17 Royal Bank Of Canada Virtualisation et traitement securise de donnees
GB2508015A (en) * 2012-11-19 2014-05-21 Mastercard International Inc Method and apparatus for secure card transactions
US8990942B2 (en) * 2013-02-18 2015-03-24 Wipro Limited Methods and systems for API-level intrusion detection
US10489755B2 (en) * 2013-06-18 2019-11-26 Paypal, Inc. Merchant controlled point of sale
SG11201510302XA (en) * 2013-06-18 2016-01-28 Ciambella Ltd Method and apparatus for customized software development kit (sdk) generation
ITGE20130075A1 (it) * 2013-07-30 2015-01-31 Paybay Networks Srl Sistema per la distribuzione di applicazioni software su terminali di pagamento pos
US10504075B2 (en) * 2014-03-10 2019-12-10 Aliaswire, Inc. Methods, systems, and devices to dynamically customize electronic bill presentment and payment workflows
US10216281B2 (en) * 2014-11-02 2019-02-26 Clover Network, Inc. Systems and methods for adjusting point-of-sale interfaces
US10235676B2 (en) * 2015-05-12 2019-03-19 The Toronto-Dominion Bank Systems and methods for accessing computational resources in an open environment
US10685352B2 (en) * 2015-11-09 2020-06-16 Paypal, Inc. System, method, and medium for an integration platform to interface with third party channels
US10664812B2 (en) * 2015-11-13 2020-05-26 Paypal, Inc. Software development kits for point-of-sale device and mobile device interactive frameworks
EP3182357A1 (fr) * 2015-12-18 2017-06-21 Mastercard International Incorporated Système et procédé destinés à fournir des instructions à un dispositif de paiement
US12118487B2 (en) * 2016-02-26 2024-10-15 Micro Focus Llc Differences in hierarchical levels of information technology workflows
US20180181378A1 (en) * 2016-02-28 2018-06-28 Alex Bakman Method, system and apparatus for generating, editing, and deploying native mobile apps
US10331416B2 (en) * 2016-04-28 2019-06-25 Microsoft Technology Licensing, Llc Application with embedded workflow designer
US11651343B2 (en) * 2016-07-06 2023-05-16 PowerPay, LLC Systems and method for payment transaction processing with payment application driver
US10692055B2 (en) * 2016-07-29 2020-06-23 Square, Inc. Reprogrammable point-of-sale transaction flows
WO2018090083A1 (fr) * 2016-11-15 2018-05-24 Westpac Banking Corporation Traitement de paiement électronique
CN106897066B (zh) * 2017-02-24 2019-10-29 百富计算机技术（深圳）有限公司 基于pos支付终端的网络应用运行方法及装置
US10311421B2 (en) * 2017-06-02 2019-06-04 Bluefin Payment Systems Llc Systems and methods for managing a payment terminal via a web browser
US20190114598A1 (en) * 2017-10-18 2019-04-18 Mastercard International Incorporated Payment network as a platform
US11544238B2 (en) * 2017-11-30 2023-01-03 Ncr Corporation Custom data aggregation and integration processing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100228683A1 (en) * 2009-03-06 2010-09-09 TxVia, Inc. Issuing systems, acquiring systems, and payment networks/systems development
WO2013056104A1 (fr) * 2011-10-12 2013-04-18 C-Sam, Inc. Plateforme mobile d'activation de transaction sécurisée à plusieurs étages
US20150339107A1 (en) * 2014-05-22 2015-11-26 Oracle International Corporation Generating runtime components
US20160378439A1 (en) * 2015-06-29 2016-12-29 Oracle International Corporation Cloud based editor for generation of interpreted artifacts for mobile runtime

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11762702B1 (en) 2022-04-20 2023-09-19 Snowflake Inc. Resilience testing using a declarative engine for workloads (DEW)

Also Published As

Publication number Publication date
US20220366393A1 (en) 2022-11-17
FR3097672A1 (fr) 2020-12-25
CA3143068A1 (fr) 2020-12-24
AU2020296966A1 (en) 2022-01-27
BR112021025579A2 (pt) 2022-03-08
EP3987390A1 (fr) 2022-04-27

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
EP1771827A1 (fr) Procede et systeme de paiement electronique universel
EP3132399B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP3039628A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants
WO2020254761A1 (fr) Système d'applications de service pour terminaux de paiement
WO2019016470A1 (fr) Procédé et système de gestion d'un paiement par porte-monnaie électronique
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
EP3132404B1 (fr) Module d'émulation d'au moins une carte de paiement, procédé, dispositif de paiement, produit programme d'ordinateur et medium de stockage correspondants
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
EP3113094B1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
FR3023640A1 (fr) Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
EP3349161A1 (fr) Procédé de traitement d'une transaction de paiement, borne de paiement et programme correspondant
US20220188787A1 (en) Blockchain-based transaction kiosk
FR2962830A1 (fr) Serveur, terminal et procede de transaction securisee
EP2833262B1 (fr) Procédé d'installation d'une application sur un élément sécurisé
FR2992806A1 (fr) Systeme de transmission securisee de donnees numeriques
WO2018108558A1 (fr) Procédé et système pour effectuer des transactions sécurisées notamment dans l'internet des objets
à Nijeholt et al. Strape SDK
WO2017216494A1 (fr) Procede de selection d'au moins un service de paiement par porte-monnaie electronique propose par un etablissement financier
OA19018A (en) Procédé de sélection d'au moins un service de paiement par porte-monnaie électronique proposé par un établissement financier.
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication

Legal Events

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

Ref document number: 20785770

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3143068

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112021025579

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2020296966

Country of ref document: AU

Date of ref document: 20200617

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020785770

Country of ref document: EP

Effective date: 20220121

REG Reference to national code

Ref country code: BR

Ref legal event code: B01E

Ref document number: 112021025579

Country of ref document: BR

Free format text: APRESENTAR A TRADUCAO SIMPLES DA FOLHA DE ROSTO DA CERTIDAO DE DEPOSITO DA PRIORIDADE FR1906735 DE 21/06/2019 OU DECLARACAO CONTENDO, OBRIGATORIAMENTE, TODOS OS DADOS IDENTIFICADORES DESTA CONFORME O ART. 15 DA PORTARIA 39/2021. OS DOCUMENTOS APRESENTADOS NAO ESTAO TRADUZIDOS E A DECLARACAO NAO CONTEM OS DADOS IDENTIFICADORES DA PRIORIDADE.

REG Reference to national code

Ref country code: BR

Ref legal event code: B01Y

Ref document number: 112021025579

Country of ref document: BR

Free format text: ANULADA A PUBLICACAO CODIGO 1.5 NA RPI NO 2666 DE 08/02/2022 POR TER SIDO INDEVIDA.

ENP Entry into the national phase

Ref document number: 112021025579

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20211217