WO2025176302A1

WO2025176302A1 - Method of authenticating account data, transaction program, computer-readable data carrier, computing device and transaction system comprising same

Info

Publication number: WO2025176302A1
Application number: PCT/EP2024/054571
Authority: WO
Inventors: Dietmar Maierhöfer
Original assignee: Giesecke and Devrient ePayments GmbH
Current assignee: Giesecke and Devrient ePayments GmbH
Priority date: 2024-02-22
Filing date: 2024-02-22
Publication date: 2025-08-28
Anticipated expiration: 2026-08-22

Abstract

A method for authenticating account data (D) of a vendor (A) in electronic commerce environments, a transaction program (10), a computer-readable data carrier (11) having stored thereon a transaction program (10), a computing device (2) configured to carry out a transaction program (10) and/or comprising a computer-readable data-carrier, and a corresponding transaction system (1) for authenticating account data (D) of a vendor (A) in electronic commerce environments are provided, the method comprising the steps of providing the account data (D) on a vendor website (5); obtaining the account data (D) from the vendor (A) with a payment application (7) accessible by the customer (B); retrieving authentication information (G) from a secure database (9) associated with the vendor website (5) with the payment application; and authenticating the account data (D) in the payment application (6).

Description

METHOD OF AUTHENTICATING ACCOUNT DATA, TRANSACTION PROGRAM, COMPUTER-READABLE DATA CARRIER, COMPUTING DEVICE AND TRANSACTION SYSTEM COMPRISING SAME

Technical Field

The present disclosure relates to the field of manufacturing securing financial transactions to be carried out by customers in electronic commerce environments (e-commerce). In particular, the present disclosure relates to a method for authenticating account data of a vendor in electronic commerce environments, to a transaction program, to a computer- readable data carrier, to a computing device, and to a transaction system for authenticating publicly available account data of a vendor in electronic commerce environments.

Background of the Invention

Methods and systems for securing financial transactions in e-commerce environments are known from the prior art. Such financial transactions mainly take place when customer purchase goods in e-commerce environments, such as online shops, via the Internet, or alike. The financial transactions have to be secured against any unauthorised access to any data involved in the transactions and respective communications, so that the data, such as access data to accounts and/or transaction codes of customers and/or vendors involved, cannot be misused in a fraudulent way. WO 2014/193902 A2, for example, relates to authenticating and securing online purchases. The present invention recognizes that an account holder may initiate a financial transaction from a home computer, cellular telephone, or some other electronic device or node which the account holder controls. Prior to initiating an online purchase, the present invention requires the account holder to upload or provide a unique identifier associated with the node to the financial institution associated with the financial account of the user. The financial account may thereafter check whether the request for an online transaction was initiated with the trusted node by comparing the unique identifier of the requesting node with the unique identifier on file for the user. If the unique identifiers match, the financial institution authenticates the financial transaction and allows it to proceed. If the unique identifiers do not match, the financial institution rejects the financial transaction.

US 7 716 129 B1 describes an an electronic payment method, wherein the payer transmits to an authentication agency details of a proposed payment including an identifier associated with the payer, an identifier associated with the payee, and the payment amount. The authentication agency creates an authentication code relating to the payment and transmits it to a communications device associated with the payer. The payer receives the authentication code on the payer's communications device and transmits it, together with a secret identification code, back to the authentication agency. The authentication agency verifies the authentication code and the secret identification code and authorizes payment. Thereafter, a customer agency pays the payment amount to the payee.

WO 99/66436 Al deals with a distributed verified trusted third-party system (VPS) and method enable electron! c/digi tai transactions through real-time verification and authentication, with improved privacy and security, encompassing the whole payment range from very large to very small. The VPS includes hubs storing client data and connecting clients to vendors to mediate secure electronic transactions. Date may be preregistered by banks and other owners, controllers, and issuers of payment systems. Owners of payment systems, such as corporate/purchase cards, may authorize usage by third parties within specified limits, thus enabling them to monitor and control delegated authority. A central account authority provides registration services indicating which hub services which client. The VPS implements a dual key transaction system, in which verified instructions must come separately and completely independently from both client and vendor before transaction completion via methods accepted by both parties. The VPS allows the client, the vendor, and associated payment methods and systems to be known, with fixed quantities and pre-registered within an authorization manager. The client and vendor may choose the payment method and currency used at each end of any transaction, and payment is always made within a closed system without either party having access to or knowing the details of the other's payment system. Real-time audit trails for all parties concerned are implemented, in which client, vendors, and banks may trace transactions, generate reports, and initiate refunds for such secure transactions. The VPS is also software and/or hardware independent, implemented by any known networking configuration for any known electronic or digital transaction, using mobile phones, palm-tops and digital television for purchases and credit/debit payment arrangements for any form of commerce using electronic transactions.

Methods and systems for securing financial transactions in e-commerce environments according to the prior art, as described above, may not fully satisfy all requirements regarding certain security concerns. Certain security concerns can arise in e-commerce environments, which allow direct payments between vendors and customers, such as through electronic account numbers, e.g., an International Bank Account Number (IBAN), are used, so that a customer can carry out a direct payment from his own account to a vendors account without the use of intermediaries, such as credit card companies. An example for such payments would be SEPA Credit Transfer (SCT) initiated payments by consumer safter purchasing goods in an online shop (advanced payment or invoice-based payment). One way of then misleading a customer in order to obtain data involved in an unauthorised way could be so-called browser hijacking, where any kind of malware modifies a web browser setting without notifying the customer, to then replace an e- commerce website, or at least a part thereof, with a fake homepage, or other fraudulent data, that may mislead the customer. Summary of the Invention

It may thus be seen as an object to provide a way of securing e-commerce transactions in environments that allow direct payments. In particular, can be seen as an object to secure data of customers and/or vendors against unauthorised access and/or manipulation. These objects are at least partly achieved by the subject-matter of the independent claims.

According to an aspect, a method for authenticating account data of a vendor in electronic commerce environments, the method comprising the steps of providing the account data on a vendor website; obtaining the account data from the vendor with a payment application accessible by the customer; retrieving authentication information from a secure database associated with the vendor website with the payment application; and authenticating the account data in the payment application.

According to an aspect, a transaction program is provided, comprising instructions which, when the program is executed by a computing device, cause the computing device to carry out a corresponding method.

According to an aspect, a computer-readable data carrier having stored thereon a corresponding transaction program is provided.

According to an aspect, a computing device configured to carry out a corresponding transaction program and/or comprising a corresponding computer-readable data-carrier is provided.

According to an aspect, a transaction system for authenticating account data of a vendor in electronic commerce environments is provided, configured to carry out a corresponding method, comprising a corresponding transaction program, comprising a corresponding computer-readable data-carrier, and/or comprising a corresponding computing device. The account data may comprise an account number, such as an IBAN. The customer to may be led to the account data through a link provided in the electronic commerce environment and/or the account data may be made publicly available. The transaction program may provide the payment application. The payment application may be executed on a server and/or on a mobile device operated by the customer. The secure database may a include and/or be a Domain Name System (DNS).

The proposed solution has the advantage over the prior art, that in particular visible information on the website which may be read by the user may be provided in the form of a scannable code, such as a QR-code, can be authenticated. Since, according to the prior art, an e-commerce consumer usually does not know, whether account data, e.g., an IBAN provided by an online merchant is actually matching with the online shop where the consumer is purchasing goods or services, the proposed solution allows a respective authentication/verification. This allows the user is to trust that the visible information, e.g., IBAN, is not tampered or modified by attacks and really belongs to the online merchant or contracted PSP. Therefore, the proposed solution allows for significantly enhancing security of e-commerce transactions without the need of directly involving third parties, such as payment providers, or other trusted entities, in the transaction.

Further developments can be derived from the dependent claims and from the following description. Features described with reference to a transaction system and components thereof may be implemented as method steps, or vice versa. Therefore, the description provided in the context of the transaction system and its components applies in an analogous manner also to respective methods. In particular, features and functions of the transaction system and of its components may be implemented as method steps of the method and the method steps may be implemented as respective features or functions of the transaction system.

According to a possible embodiment of a method, the authentication information comprises a digital certificate. The digital certificate may be issued from third parties, for example, and made us help to authenticate the account data. This further helps in avoiding any tampering with the account data and therefore further enhances security of e- commerce transactions.

According to a possible embodiment of a method, the authentication information comprises a server certificate authenticating the vendor website. Providing a server certificate from a respective server allows for securing the authentication information against unauthorised access. Thereby, any tampering with the account data and/or the certificate can be avoided, and the security of e-commerce transactions further enhanced.

According to a possible embodiment of a method, the server certificate is used for authenticating the account data. The server certificate may serve as the digital certificate. Thus, no further certification processes than those already used for certifying the server certificate are necessary. This helps in efficiently securing e-commerce transactions.

According to a possible embodiment of a method, the further comprising the step of digitally signing the account data as belonging to the vendor. The account data can be digitally signed by means of the digital certificate. The resulting digital signature helps in authenticating the account data in a reliable and transparent way. Thereby, e-commerce transactions may be efficiently secured.

According to a possible embodiment of a method, the authentication information includes a cryptographic key for encrypting a data connection established with the vendor website. The account data can be digitally signed by means of a private key of the domain hosting the vendor website. For example, an IBAN may be secured by signing it with the same certificate as being used for the domain, e.g., a certificate used in the Transport Layer Security (TLS) protocol for securing https connections and handing over the payment data the payment application which may be standardised according to the World Wide Web Consortium (W3C) standard. The domain and associated IBAN can be validated and shown to the consumer by the payment application. This further helps in efficiently and reliably securing e-commerce transactions. According to a possible embodiment of a method, the cryptographic key is used for validating the authentication. For example, the private key of the domain, primarily used for a secured TLS connection, is used to sign the account data of the vendor. Thereby, a fully automated and secure process can be provided to ensure that an e-commerce environment, such as an online shop, and account data, e.g., an IBAN, are valid and belong to each other. As the certificate of the domain can be found on the website, the public key may also be used to validate the signature of the account data beside the signature of the domain. Thereby, the e-commerce environment can be efficiently and reliably secured.

According to a possible embodiment of a method, further comprising the step of handing over the account data to the payment application. Thereby, the account data can be securely handled by means of the payment application. This further helps in enhancing security of the transfer of the account data from the vendor to the customer.

According to a possible embodiment of a method, the wherein the account data is transferred through an API (application programming interface) of the payment application. The API may be a standardized, for example, according to the W3C-Standard. This further helps in providing an efficient way for securing the account data.

According to a possible embodiment of a method, the account data includes payment information. The payment information may include data regarding the purchase and/or purpose of the payment. This further helps in securing the entire transaction, since not only account data itself, e.g., an IBAN, but furthermore, associated data for the individual purchase transaction can be transferred in a secure manner.

According to a possible embodiment of a method, the account data is accessible by the customer only after authentication. The account data may be displayed to the customer after authentication. Thereby, the customer can rest assured that the account data is authenticated. This further helps in providing secure and, thus trusted e-commerce environments. Brief Description of the Drawings

Fig. 1 is a schematic illustration of a transaction system for authenticating account data in line with a method according to the present invention.

Detailed Description of Embodiments

The following detailed description is merely exemplary in nature and is not intended to limit the invention and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description. The representations and illustrations in the drawings are schematic and not to scale. Like numerals denote like elements. A greater understanding of the described subject matter may be obtained through a review of the illustrations together with a review of the detailed description that follows.

Fig. 1 shows a schematic illustration of a transaction system 1, for example, the form of an e-commerce environment, for authenticating account data in line with a method according to the present invention. The transaction system 1 involves a vendor A and a customer B. Furthermore, the transaction system 1 may involve a certification entity C. The vendor A, customer B, and/or certification entity C may each operate a computing device 2 taking part in and/or as a part of transaction system 1. The vendor A and/or the certification entity C can each operate the computing device 2 to configured as a server device 3. The customer B can operate the computing device 2 configured as a client device 4.

The server device 3 of the vendor A may provide a vendor website 5 and a payment application 6. The client device 4 of the vendor B may provide a web interface 7, such as a web browser, configured to access the vendor website 5, and can run the payment application 6, either as a locally installed program being executed on the client device 4 and/or as a further part of the vendor website 5 that can be accessed via the web interface 7. The server-side payment application 6 of the vendor A and the client-side payment application 6 of the customer B may communicate through an application programming interface (API) 8. The vendor A and/or certification entity C may operate a secure database 9 on the respective server 3.

A transaction taking place between the vendor A and a customer B may have several steps S. In a first step SI, the certification entity C may issue a certificate CA,3,5 for the vendor website 5 to the vendor B, such as an SSL certificate to establish an SSL/TLS connection. This certificate is stored in the secure database 9. In a second step S2, the web interface 7 may send a session request R to the vendor website 5, particular, an Internet protocol (IP) address thereof, for establishing a secure session between the web interface 7 and the vendor website 7, i.e., between the client device 4 and server device 3, respectively.

In a third step S3, the server device 3 sends the certificate CA,3,5 back to the client device 4, possibly along with a public key Kp. In a fourth step, the client device 4 may create a session key Ks encrypted with the public key Ko. In a fifth step S5, the client device 4 may send the session key Ks back to the server device 3. In a sixth step, S6, the server device 3 decrypts the session key Ks with a private key Kp. A secure session P or private session, protected by SSL and/or TLS, for example, may be established between the server device 3 and the client device 4, and that any communication between them in the course of that secure session P is encrypted by the individual session key Ks.

During the secure session P, the customer B may want to purchase and/or order an item offered by the vendor A. The customer B may thus select the item to be purchased and/or ordered from the vendor website 5 by means of the web interface 7. In an eighth step S8, the customer B may send a payment request Q to the vendor A, for example, in that the customer selects a payment method to pay for the item to be purchased and/or ordered involving account data D and possibly payment information E of the vendor A to be transferred to the customer B. That account data D and possibly payment information E can be handed over from the vendor website 5 to the payment application 6 on the side of the vendor A within the respective server device 3 in a ninth step S9. Alternatively, or additionally, the vendor website 5 and the payment application 6 may be provided on different server devices 3. The account data D and possibly payment information E can be transferred from the payment application 6 executed on server device 3 of the vendor A to the payment application 6 executed on client device 4 of the customer B through the API 8 in a tenth step S10.

Along with the account data D and possibly payment information E, of identification information G authenticating and thus guaranteeing that the account data D and/or payment information E belongs to the vendor A can be transferred from the payment application 6 executed on server device 3 of the vendor A to the payment application 6 executed on client device 4 of the customer B through the API 8. The authentication information G may comprise the service certificate CA,3,5 and/or the session Ks key, or at least parts and/or combinations thereof, and may be thus retrieved from the secure database 9.

In an eleventh step 11 the account data D and possibly payment information E may be made available to the customer B, for example, by being displayed to the customer B through the payment application 6 and/or web interface 7, as being authenticated by means of the authentication information G. The customer B can thus trust in the account data D and/or payment information E and can carry out, announce and/or select respective transaction T based on the account data D and/or payment information E in a twelfth step S12. The transaction T can be carried out within the transaction system 1 as disclosed herein, or may involve any parts the client device 4 accesses further transaction website of a transaction provider (not shown) and/or effects the transaction T by any other means desired or required for concluding the purchase of the item selected, for example, in that the customer B transferred is a certain amount of monetary valuables which may be specified with the payment information E, such as a respective amount of money, from a customer account to a vendor account identified by means of the account data. The transaction system 1, is configured to execute a computer program 10. A computer- readable data carrier 11 can have stored thereon the computer program 10 and may take the form of a computer-readable medium 12 and/or data carrier signal 13. When carrying out the computer program 10, the transaction system 1 and any components thereof communicate as specified in the computer program 10. Parameters associated with and/or underlying the transaction system 1, any of the components thereof and/or any of the steps carried out thereby, can be defined in the computer program 10.

List of Reference Signs

1 transaction system

2 computing device

3 server device

4 client device

5 vendor website

6 payment application

7 web interface

8 application programming interface

9 secure database

10 computer program

11 computer-readable data carrier

12 computer-readable medium

13 data carrier signal

A vendor

B customer

C certification entity

CA,3,5 server certificate

D account data

E payment information

G authentication information

Ko public key

Kp private key

Ks session key

P secure/private session

Q payment request

R session request

S step

T transaction issue certificate send request return certificate/public key create session key return session key decrypt session key establish secure session payment request hand over data transfer data provide data initiate transaction

Claims

1. Method for authenticating account data (D) of a vendor (A) in electronic commerce environments, the method comprising the steps of providing the account data (D) on a vendor website (5); obtaining the account data (D) from the vendor (A) with a payment application (7) accessible by the customer (B); retrieving authentication information (G) from a secure database (9) associated with the vendor website (5) with the payment application; and authenticating the account data (D) in the payment application (6).

2. Method according to claim 1, wherein the authentication information (G) comprises a digital certificate.

3. Method according to claim 1 or 2, wherein the authentication information (G) comprises a server certificate (CA,3,S) authenticating the vendor website (5).

4. Method according to claim 3, wherein the server certificate (CA,3,S) is used for authenticating the account data (D).

5. Method according to at least one of claims 1 to 4, further comprising the step of digitally signing the account data (D) as belonging to the vendor (A).

6. Method according to at least one of claims 1 to 5, wherein the authentication information (G) includes a cryptographic key (K) for encrypting a data connection (P) established with the vendor website (5).

7. Method according to claims 1 to 6, wherein the cryptographic key (K) is used for validating the authentication.

8. Method according to at least one of claims 1 to 7, further comprising the step of handing over the account data (D) to the payment application (6).

9. Method according to at least one of claims 1 to 8, wherein the account data (D) is transferred through an API (8) of the payment application (6).

10. Method according to at least one of claims 1 to 9, wherein the account data (D) includes payment information (E).

11. Method according to at least one of claims 1 to 7, wherein the account data (D) is accessible by the customer (B) only after authentication.

12. A transaction program (10) comprising instructions which, when the program is executed by a computing device (2), cause the computing device (2) to carry out a method according to at least one of claims 1 to 11.

13. A computer-readable data carrier (11) having stored thereon a transaction program (10) according to claim 12.

14. A computing device (2) configured to carry out a transaction program (10) according to claim 12 and/or comprising a computer-readable data-carrier (11) according to claim 13.

15. A transaction system (1) for authenticating account data (D) of a vendor (A) in electronic commerce environments, configured to carry out a method according to at least one of claims 1 to 11, comprising a transaction program (10) according to claim 12, comprising a computer-readable data-carrier (11) according to claim 13, and/or comprising a computing device (2) according to claim 14.