EP3192028A1 - Method and system for conducting a cash-on-delivery (cod) transaction - Google Patents

Method and system for conducting a cash-on-delivery (cod) transaction

Info

Publication number
EP3192028A1
EP3192028A1 EP15839168.0A EP15839168A EP3192028A1 EP 3192028 A1 EP3192028 A1 EP 3192028A1 EP 15839168 A EP15839168 A EP 15839168A EP 3192028 A1 EP3192028 A1 EP 3192028A1
Authority
EP
European Patent Office
Prior art keywords
transaction
cod
payment
confirmation request
payment confirmation
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP15839168.0A
Other languages
German (de)
French (fr)
Other versions
EP3192028A4 (en
Inventor
Amit Gupta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mastercard Asia Pacific Pte Ltd
Original Assignee
Mastercard Asia Pacific Pte Ltd
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 Mastercard Asia Pacific Pte Ltd filed Critical Mastercard Asia Pacific Pte Ltd
Publication of EP3192028A1 publication Critical patent/EP3192028A1/en
Publication of EP3192028A4 publication Critical patent/EP3192028A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/16Payments settled via telecommunication systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223Realising banking transactions through M-devices

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Methods and systems for conducting cash-on-delivery (COD) transactions. An exemplary method for conducting a COD transaction, assigned a unique identifier by a server, comprises: receiving the unique identifier during delivery; generating a transaction payment confirmation request upon receipt of the unique identifier; transmitting the transaction payment confirmation request, using an open connection message session, to a client for transaction payment confirmation; receiving, from the client, a response to the transaction payment confirmation request during the open connection message session; and processing the COD transaction based on the response of the client to the transaction payment confirmation request.

Description

METHOD AND SYSTEM FOR CONDUCTING A CASH-ON-DELIVERY (COD)
TRANSACTION
TECHNICAL FIELD OF INVENTION
[001 ] The following discloses a method and system for conducting a cash- on-delivery (COD) transaction.
BACKGROUND
[002] A cash-on-delivery (COD) transaction is a type of transaction in which payment for a good or service is made at the time of delivery. Typically, payment is made using cash or credit card (using a mobile point-of-sale terminal). If the consumer does not make payment when the good or service is delivered, the good or service is returned to the merchant.
[003] There are several problems associated with current COD transactions. For merchants, additional resources have to be spent to handle the payment made by the consumer, and delivery timings have to coincide with the availability of the consumer. For example, merchants may have to pay couriers a cash handling fee for collecting the payment on behalf of the merchant and subsequently settling the payment with the merchant. In the case of credit card payment, the mobile point-of-sale terminals that are used are usually very costly. For consumers, they have to be physically present at the time of delivery in order to make payment. If credit card payment is not accepted, consumers need to have cash on-hand.
[004] Advanced COD payment techniques exist that can address the above- mentioned problems, but they utilize an Internet connection. These solutions have low penetration rates in emerging markets as many consumers may not have smartphones that have connection to the Internet (GPRS/3G/4G connection).
[005] A need therefore exists to provide method(s) and system(s) for conducting a transaction that seeks to address at least the above-mentioned problems.
SUMMARY
[006] According to a first aspect of the invention, there is provided a method for conducting a cash-on-delivery (COD) transaction assigned a unique identifier by a server, the method comprising: receiving the unique identifier during delivery; generating a transaction payment confirmation request upon receipt of the unique identifier; transmitting the transaction payment confirmation request, using an open connection message session, to a client for transaction payment confirmation; receiving, from the client, a response to the transaction payment confirmation request during the open connection message session; and processing the COD transaction based on the response of the client to the transaction payment confirmation request.
[007] In an embodiment, the open connection message session may use an unstructured supplementary services data (USSD) protocol.
[008] In an embodiment, the method may further comprise generating, at the server, the unique identifier for the transaction.
[009] In an embodiment, the response of the client to the transaction payment confirmation request may comprise a selection of a payment instrument (e.g. a debit or credit card account) for payment of the COD transaction.
[010] In an embodiment, the method may further comprise authenticating the client, during the open connection message session, after receiving the client's response to the transaction payment confirmation request.
[01 1 ] In an embodiment, processing of the COD transaction may comprise verification of the COD transaction by an issuing entity that issues the payment instrument.
[012] In an embodiment, the unique identifier may be received from a courier service that undertakes the delivery. The courier service may complete the delivery to the client upon successful verification of the COD transaction by the issuing entity.
[013] According to a second aspect of the invention, there is provided a system for conducting a cash-on-delivery (COD) transaction, the system comprising a server in wireless communication with a mobile electronic device used to facilitate the transaction, the server comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to: assign a unique identifier to the COD transaction; receive the unique identifier during delivery; generate a transaction payment confirmation request upon receipt of the unique identifier; transmit the transaction payment confirmation request, using an open connection message session, to the mobile electronic device for transaction payment confirmation; receive, from the mobile electronic device, a response to the transaction payment confirmation request during the open connection message session; and process the COD transaction based on the response to the transaction payment confirmation request.
[014] In an embodiment, the open connection message session may use an unstructured supplementary services data (USSD) protocol.
[015] In an embodiment, the server may be further caused to generate the unique identifier.
[016] In an embodiment, the response to the transaction payment confirmation request may comprise a selection of a payment instrument for payment of the COD transaction.
[017] In an embodiment, the server may be further caused to authenticate a user of the mobile electronic device, during the open connection message session, after receiving the response to the transaction payment confirmation request.
[018] In an embodiment, the processing of the COD transaction may comprise verification of the COD transaction by an issuing entity that issues the payment instrument.
[019] In an embodiment, the unique identifier may be received from a courier service that undertakes the delivery to the user of the mobile electronic device. The courier service may complete the delivery to the user of the mobile electronic device upon successful verification of the COD transaction by the issuing entity.
BRIEF DESCRIPTION OF THE DRAWINGS
[020] Embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:
[021 ] Figure 1 is a schematic of a system for conducting a transaction, according to an embodiment of the invention;
[022] Figure 2 is a schematic of an exemplary computing device to realize a server that may be used to realize the payment network module, issuer server and /or acquirer server shown in Figure 1 ; [023] Figure 3 is a schematic of an exemplary wireless electronic communication device that may be utilized to implement the mobile electronic device shown in Figure 1 ;
[024] Figure 4 shows a flowchart depicting steps of a method for conducting a transaction, which are implemented in the system of Figure 1 ;
[025] Figure 5 shows a schematic of a server to realize at least a portion of the payment network module shown in Figure 1 ;
[026] Figure 6 shows a snapshot of an exemplary USSD message that is displayed on a courier service's mobile phone.
[027] Figures 7a, b, c, d show snapshots of exemplary USSD messages that are displayed on the consumer's mobile phone during the payment request phase; and
[028] Figures 8a, b, c show snapshots of exemplary USSD messages that are displayed on the consumer's, merchant's and courier service's mobile phone, respectively, during the confirmation phase.
DETAILED DESCRIPTION
[029] Figure 1 is a schematic of a system 100 for conducting a transaction. The system 100 comprises a mobile electronic device 102, such as a mobile phone, PDA or tablet having similar functionality, a merchant device 104, a communications module 106, an acquirer server 108, a payment network module 1 10 and an issuer server 1 12.
[030] The mobile electronic device 102 is in wireless communication with the payment network server 1 10 via the communications module 106. The merchant device 104 is in communication with the payment network module 1 10. The payment network module 1 10 is in communication with the acquirer server 1 08 and with the issuer server 1 12. For simplicity, the components in the system 100 are represented by single units (e.g. one mobile electronic device 102, one merchant device 104, etc). However, it will be appreciated by a person skilled in the art that the system 100 can accommodate more than one unit of each component (e.g. a plurality of mobile electronic devices and/or merchant devices).
[031 ] Use of the term 'served herein may be understood to mean a single computing device or a plurality of interconnected computing devices which operate together to perform a particular function. That is, the server may be contained within a single hardware unit or be distributed among several or many different hardware units. An exemplary computing device which may be operated as a server is described below with reference to Figure 2.
[032] Turning back to Figure 1 , a consumer (e.g. a client who wishes to purchase a good or service from a merchant) is a party to a transaction. Here, the transaction refers to a cash-on-delivery (COD) transaction in which payment for a good or service is made at the time of delivery of that good or service to the customer. Payment is made using a payment instrument such as a debit or credit card. The consumer uses the mobile electronic device 102 to facilitate the COD transaction, e.g. to authorize payment for the good or service.
[033] The merchant device 104 is associated with the merchant who is also a party to the transaction. The merchant device 104 may be a point-of-sale (POS) terminal, a personal computer, a computer server (hosting a website, for example), a land-line telephone, or any type of mobile device such as a mobile phone, a laptop computer, a tablet computer and the like. The communications module 106 facilitates wireless and hence mobile communication between the mobile electronic device 102 and the payment network module 1 10. In an exemplary implementation, the communications module 106 supports communication via an open connection message session using an unstructured supplementary services data (USSD) protocol. The open connection message session is a real-time session that ends after the purpose for which the open connection message session was initiated is complete. In the context of an implementation of a COD transaction, this purpose is to transmit a transaction payment confirmation request and to receive a response to the request. The communications module 106 comprises a switching centre / signal transfer point (MSC/STP) module 106a and a home location register / visitor location register (HLR/VLR) module 106b such as may be found in a cellular telephone base station.
[034] USSD is a protocol used by GSM cellular telephones (e.g. the mobile electronic device 102) to communicate with computers (e.g. the payment network module 1 10). A GPRS/3G connection is not required for USSD communication as it operates on the voice channel. A USSD message contains up to 182 alphanumeric characters and unlike short message service (SMS) messages, USSD messages create a real-time connection during a USSD session. The connection remains open, allowing a two-way exchange of a sequence of data. A typical USSD session displays text similar to an interactive menu and incoming messages are of flash type and messages are not stored on the GSM cellular telephone (unlike, e.g. SMS messages). As such, USSD is more secure than SMS messaging.
[035] USSD communication does not require installation of a dedicated software application on the GSM cellular telephone. The USSD service codes may be stored on a subscriber identity module (SIM) card.
[036] In emerging markets, many consumers own "feature phones" without connection to the Internet. That is, many consumers do not own smartphones that have connection to the Internet (e.g. GPRS/3G/4G connection). However, most GSM "feature phones" are able to support USSD messaging. As such, consumers with such phones can participate in COD transactions according to embodiments of the invention.
[037] The home location register (HLR) is the "home zone" where the GSM cellular telephone numbers are registered in the database. The visitor location register (VLR) is where the GSM cellular telephone numbers are registered when the user is roaming.
[038] The acquirer server 108 is associated with an acquiring entity who may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) an account (e.g. a financial bank account) of the merchant. Examples of the acquiring entity include a bank and/or other financial institution. The acquirer server 108 may include one or more computing devices that are used to establish communication with another server by exchanging messages with and/or passing information to the other server.
[039] The payment network module 1 10 is associated with a payment facilitator. The payment facilitator may be an entity (e.g. MasterCard®) that facilitates the processing of transactions, such as clearing and settling funds for payments between two or more entities (e.g. two banks). The payment network module 1 10 includes a USSD gateway 1 10a and a database 1 10b. The USSD gateway allows the payment network module 1 10 to communicate with the mobile electronic device 102 through the USSD protocol. The payment network module 1 10 also includes one or more servers / computing devices (not shown) that are used for processing transactions and/or managing the database.
[040] The issuer server 1 12 is associated with an issuing entity and may include one or more computing devices that are used to perform a payment transaction. The issuing entity may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) an account (e.g. a financial bank account) of the consumer. The issuing entity primarily provides payment instruments, such as a credit or a debit card, for holders (i.e. consumers) of such instruments to make purchases from the merchant. The card issuer typically provides the owner of such payment instruments a credit line (especially in the case of the credit card) against which is checked whether there are sufficient funds to pay for a transaction initiated by the holder of a payment instrument.
[041 ] Although the system 1 00 can accommodate multiple consumers (clients), for the sake of brevity, the following description relates to one consumer initiating a COD transaction with a merchant.
[042] In an implementation, a registration phase is completed before a COD transaction can be initiated. The registration phase involves consumers providing the following information to the payment facilitator: (i) name or exclusive identity, (ii) mobile phone number, and (iii) debit or credit card number(s). More than one debit or credit card of the consumer can be registered. Optionally, the address of the consumer may be provided. The payment facilitator may store some or all of this information in the database 1 10b. The information may be provided to the payment facilitator using any suitable means, e.g. registration through a secure online website.
[043] The registration phase also involves merchants providing the following mandatory information to the payment facilitator: (i) doing-business-as (DBA) name, (ii) legal name, (iii) acquiring entity, and (iv) mobile phone number. Optionally, the address of the merchant may be provided. The payment facilitator may store this information in the database 1 10b. The information may be provided to the payment facilitator using any suitable means, e.g. registration through a secure online website. The merchant's mobile phone number is obtained so that payment confirmation (i.e. payment has been made on delivery) can be received on the mobile phone. Also, notifications can be received on the mobile phone should the merchant also take on the delivery of the good or service.
[044] Once the necessary information is provided, the consumer / merchant may receive a confirmation message from the payment facilitator and the registration phase can be considered complete. The registration is preferably performed only once; thereafter, the registered consumer / merchant can participate in COD transactions according to embodiments of the invention.
[045] The transaction phase comprises steps 1 to 1 1 , and will be described in detail with reference to Figure 1 . At step 1 , a consumer wishes to purchase a product from a merchant. The consumer places the order (e.g. indicates the product and corresponding quantity; and that he wishes to pay on delivery (i.e. selects a COD transaction option)) and provides his registered mobile phone number (that was registered during the above described registration phase). In an online commerce environment, the order can be placed and the mobile phone number can be provided through the merchant's secure online website. In a "brick & mortar" environment (i.e. the consumer is present at the merchant's physical store), the order can be placed and the mobile phone number can be provided through the cashier.
[046] At step 2, using the merchant device 104, the merchant sends the order details (e.g. product identifier, quantity purchased, COD transaction option, etc.) and the consumer's registered mobile phone number / address to the payment network module 1 10.
[047] The information received from the merchant device 104 is saved on the database 1 10b. In addition, the payment network module 1 10 generates a transaction identifier that is unique to the COD transaction. The transaction identifier may be associated with one or more of: the merchant, the consumer and the purchased product details. For example, the transaction identifier can be generated based on the merchant's identifier (e.g. registered DBA name) and the transaction number.
[048] The generated transaction identifier is stored in the database 1 10b. For example, the database can be arranged such that each COD transaction is linked to its corresponding transaction identifier, merchant, consumer and purchased product details. In this manner, the transaction identifier can be used to track the order; and identify the merchant and consumer by accessing the database (e.g. via a look-up procedure).
[049] In this implementation, the payment network module 1 10 generates the transaction identifier that is unique to the COD transaction. This is in contrast to the prior art, where the transaction identifier is typically generated by the merchant (e.g. using the merchant device 104). If the transaction identifiers are generated by merchants, there may be a possibility of duplicate transaction identifiers as one merchant may not be aware of the transaction identifiers generated by another merchant. If the transaction identifiers are centrally generated by the payment network module 1 10, a particular transaction at a particular merchant can be assigned a unique transaction identifier. That is, a transaction identifier is unique across multiple merchants. [050] At step 3, the generated transaction identifier is sent to the merchant device 104. At step 4, the merchant notifies the consumer of the transaction identifier and that the order placement is successful. For example, in an online commerce environment, the transaction identifier and notification are displayed on the merchant's secure online website. In a "brick & mortar" environment, the cashier can inform the consumer and provide a receipt with the transaction identifier and order confirmation.
[051 ] At this stage, the transaction identifier is known to the consumer, merchant and payment facilitator. At step 5, the purchased product is delivered by a courier service 1 14. The courier service 1 14, who may be a third party engaged by the merchant to undertake the delivery, or an employee of the merchant, is also aware of the transaction identifier associated with the product that is being delivered. For example, the transaction identifier may be indicated on the delivery chit.
[052] At step 6, at the point of delivery, the courier service 1 14 sends the transaction identifier to the payment network module 1 10 via any suitable means. For example, the courier service uses a mobile phone to dial a specific code that routes him to the payment network module 1 10. Figure 6 shows a snapshot of an exemplary USSD message that is displayed on the courier service's mobile phone. The courier service dials "*99" to access the payment network module 1 10, and enters the transaction identifier "123456". Unlike the prior art, the courier service 1 14 does not require a mobile POS terminal. At step 7, upon receipt of the transaction identifier, the payment network module 1 10 sends a payment confirmation request to the consumer's mobile electronic device 102 via the communications module 1 06. The payment request is sent by way of a USSD message using the communications module 106.
[053] The mobile electronic device 102 receives and displays the USSD message, which includes various options including whether or not to pay for the delivered product and which debit / credit card to use for payment.
[054] At step 8, the consumer uses the mobile electronic device 102 to communicate the various choices to the payment network module 1 10 via the USSD session. The USSD session also involves an authentication phase, e.g. the consumer is requested to provide his personal identification number (PIN). Figures 7a, b, c, d show snapshots of exemplary USSD messages that are displayed on the consumer's mobile phone during the payment request phase. First, as shown in Figure 7a, a consumer selects an issuing bank which the consumer has an account with. Subsequently, as shown in Figure 7b, the consumer selects the credit / debit card from then chosen issuing bank. Thereafter, as shown in Figure 7c, the consumer is requested to provide his PIN. The consumer may also be required to input one or more of: transaction identifier, merchant name and amount to be paid. Assuming the payment is successful, a payment confirmation is received, as shown in Figure 7d.
[055] At step 9, transaction details and debit / credit card data (e.g. card number, expiry date, name, card verification value (CVV) number and/or PIN) are sent from the payment network module 1 10 to the issuer server 1 12 for further processing (e.g. verification / authorisation) of the transaction. For example, the issuer server 1 12 checks if there is sufficient funds / credit in the consumer's bank account. If there is, the transaction is authorised. Otherwise, the transaction is declined.
[056] Assuming that the transaction is successfully verified / authorised, at step 10, a transaction confirmation message is sent to the payment network module 1 10. At step 1 1 , the payment network module 1 10 sends the transaction confirmation message to the courier service 1 14, merchant device 104 and the consumer's mobile electronic device 102. In an implementation, the transaction confirmation message is sent to the consumer's mobile electronic device 1 02 as a USSD message via the communications module 106. Figures 8a, b, c show snapshots of exemplary USSD messages that are displayed on the consumer's, merchant's and courier service's mobile phone, respectively, during the confirmation phase. As shown in Figure 8a, the consumer is informed that payment is successful for the particular transaction, and payment is debited from the chosen credit / debit card account. As shown in Figure 8b, the merchant is informed that payment has been made. As shown in Figure 8c, the merchant is informed that payment has been made so that he can hand over the product to the consumer.
[057] Upon receipt of the transaction confirmation message, the courier service 1 14 hands over the product to the consumer.
[058] At step 12, the payment network module 1 10 sends information (e.g. card number, expiry date, name, card verification value (CVV) number and/or PIN) to the acquirer server 108 for further processing (e.g. clearing) of the transaction by the acquiring entity.
[059] Figure 2 shows an exemplary computing device 200, to realize a server that can be used to realize the payment network module 1 10, issuer server 1 12 and /or acquirer server 108 shown in Figure 1 . The following description of the computing device 200 is provided by way of example only and is not intended to be limiting. Therefore, one or more elements / components of the computing device 200 may be omitted. Also, one or more elements / components of the computing device 200 may be combined together. Additionally, one or more elements / components of the computing device 200 may be split into one or more component parts.
[060] With reference to Figure 2, the exemplary computing device 200 includes a processor 203 for executing software routines. Although a single processor is shown for the sake of clarity, the computing device 200 may also include a multi-processor system. The processor 203 is connected to a communication infrastructure 206 for communication with other components of the computing device 200. The communication infrastructure 206 may include, for example, a communications bus, cross-bar, or network.
[061 ] The computing device 200 further includes a main memory 207, such as a random access memory (RAM), and a secondary memory 210. The secondary memory 210 may include, for example, a hard disk drive 212 and/or a removable storage drive 214, which may include a magnetic tape drive, an optical disk drive, or the like. The removable storage drive 214 reads from and/or writes to a removable storage unit 218 in a well-known manner. The removable storage unit 218 may include a magnetic disk, optical disk, or the like, which is read by and written to by removable storage drive 214. As will be appreciated by persons skilled in the relevant art(s), the removable storage unit 218 includes a computer readable storage medium having stored therein computer executable program code instructions and/or data.
[062] In an alternative implementation, the secondary memory 210 may additionally or alternatively include other similar means for allowing computer programs or other instructions to be loaded into the computing device 200. Such means can include, for example, a removable storage unit 222 and an interface 250. Examples of a removable storage unit 222 and interface 250 include a program cartridge and cartridge interface, a removable memory chip (such as an EPROM or PROM) and associated socket, and other removable storage units 222 and interfaces 250 which allow software and data to be transferred from the removable storage unit 222 to the computing device 200.
[063] The computing device 200 also includes at least one communication interface 224. The communication interface 224 allows software and data to be transferred between computing device 200 and external devices via a communication path 226. In various implementations, the communication interface 224 permits data to be transferred between the computing device 200 and a data communication network, such as a public data or private data communication network. The communication interface 224 may be used to exchange data between different computing devices 200 which such computing devices 200 form part an interconnected computer network. Examples of a communication interface 224 can include a modem, a network interface (such as an Ethernet card), a communication port, an antenna with associated circuitry and the like. The communication interface 224 may be wired or may be wireless. Software and data transferred via the communication interface 224 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communication interface 224. These signals are provided to the communication interface via the communication path 226.
[064] As shown in Figure 2, the computing device 200 further includes a display interface 202 which performs operations for rendering images to an associated display 230 and an audio interface 232 for performing operations for playing audio content via associated speaker(s) 234.
[065] As used herein, the term "computer program product" may refer, in part, to removable storage unit 218, removable storage unit 222, a hard disk installed in hard disk drive 212, or a carrier wave carrying software over communication path 226 (wireless link or cable) to communication interface 224. A computer readable medium can include magnetic media, optical media, or other recordable media, or media that transmits a carrier wave or other signal. These computer program products are devices for providing software to the computing device 200. Computer readable storage medium refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computing device 200 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray Disc™, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computing device 200. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computing device 200 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. [066] The computer programs (also called computer program code) are stored in main memory 207 and/or secondary memory 210. Computer programs can also be received via the communication interface 224. Such computer programs, when executed, enable the computing device 200 to perform one or more steps that facilitate the conduct of transactions, as described above with reference to Figure 1 . The computer programs, when executed, enable the processor 203 to facilitate the conduct of transactions. Accordingly, such computer programs may represent controllers of the computing device 200.
[067] Software may be stored in a computer program product and loaded into the computing device 200 using the removable storage drive 214, the hard disk drive 212, or the interface 250. Alternatively, the computer program product may be downloaded to the computing device 200 over the communications path 226. The software, when executed by the processor 203, causes the computing device 200 to perform the necessary operations to execute one or more steps that facilitate the conduct of transactions, as described above with reference to Figure 1 .
[068] Figure 3 is a schematic of an exemplary wireless electronic communication device 300 that may be utilized to implement the mobile electronic device 102 shown in Figure 1 . The wireless device 300 comprises a keypad 302, a display screen 304, a microphone 306, a speaker 308 and an antenna 31 0. The wireless device 300 is capable of being operated by a user to perform a variety of different functions, such as, for example, hosting a telephone call and sending a SMS or USSD message.
[069] The wireless device 300 comprises hardware to perform communication functions (e.g. telephony, data communication), together with an application processor and corresponding support hardware to enable the wireless device 300 to have other functions, such as, messaging and the like. The communication hardware is represented by the RF processor 312 which provides an RF signal to the antenna 310 for the transmission of data signals, and the receipt therefrom. Additionally provided is a baseband processor 314, which provides signals to and receives signals from the RF processor 312. The baseband processor 314 also interacts with a subscriber identity module 316, as is well known in the art. The communication subsystem enables the wireless device 300 to communicate via a number of different communication protocols including GSM. The communication subsystem of the wireless device 300 is beyond the scope of the present invention. [070] The keypad 302 and the display screen 304 are controlled by an application processor 318. A power and audio controller 320 is provided to supply power from a battery 322 to the communication subsystem, the application processor 318, and the other hardware. The power and audio controller 320 also controls input from the microphone 306, and audio output via the speaker 308.
[071 ] In order for the application processor 318 to operate, various different types of memory are provided. Firstly, the wireless device 300 includes Random Access Memory (RAM) 326 connected to the application processor 318 into which data and program code can be written and read from at will. Code placed anywhere in RAM 326 can be executed by the application processor 318 from the RAM 326. RAM 326 represents a volatile memory of the wireless device 300.
[072] Secondly, the wireless device 300 is provided with a long-term storage 328 connected to the application processor 318. The long-term storage 328 comprises three partitions, an operating system (OS) partition 330, a system partition 332 and a user partition 334. The long-term storage 328 represents a non-volatile memory of the wireless device 300.
[073] In the present example, the OS partition 330 contains the firmware of the wireless device 300 which includes an operating system. Other computer programs may also be stored on the long-term storage 328, such as application programs, and the like. In particular, application programs which are mandatory to the wireless device 300 such as communications applications and the like are typically stored in the system partition 332. The application programs stored on the system partition 332 would typically be those which are bundled with the wireless device 300 by the device manufacturer when the wireless device 300 is first sold.
[074] Application programs which are added to the wireless device 300 by the user would usually be stored in the user partition 334.
[075] As stated, the representation of Figure 3 is schematic. In practice, the various functional components illustrated may be substituted into one and the same component. For example, the long-term storage 328 may comprise NAND flash, NOR flash, a hard disk drive or a combination of these.
[076] Figure 4 shows a flowchart depicting steps of a method for conducting a cash-on-delivery (COD) transaction assigned a unique identifier by a server. The method includes the following steps as detailed below and described with reference to Figure 1 . [077] In step 402, the unique identifier is received during delivery. For example, the unique identifier may be received from a courier service that is delivering a product to a client who purchased the product. The unique identifier may be generated at the server (e.g. payment network module 1 10). The generated unique identifier may be stored in a database (e.g. database 1 10b). The database can be arranged such that each COD transaction is linked to its corresponding unique transaction identifier, merchant, consumer and purchased product details. In other words, each COD transaction is assigned a unique identifier. In this manner, the transaction identifier can be used to identify / track the order; and identify the merchant and consumer by accessing the database (e.g. via a look-up procedure).
[078] In step 404, a transaction payment confirmation request is generated, at the server, upon receipt of the unique identifier.
[079] In step 406, the transaction payment confirmation request is transmitted using an open connection message session to a client for transaction payment confirmation. The open connection message session may use an unstructured supplementary services data (USSD) protocol. The transaction payment confirmation request allows the client, who is using a mobile electronic device 102, to initiate payment of the product so that the product can be handed over to him, as per typical COD transaction procedure.
[080] In step 408, a response to the transaction payment confirmation request is received from the client during the open connection message session, e.g. using the mobile electronic device 102. The client's response to the transaction payment confirmation request may comprise a selection of a payment instrument (e.g. a debit or credit card account) for payment of the COD transaction. After receiving the client's response to the transaction payment confirmation request, the client may be authenticated during the open connection message session.
[081 ] In step 410, the COD transaction is processed based on the client's response to the transaction payment confirmation request. Processing of the COD transaction may include verification of the COD transaction by an issuing entity that issues the payment instrument. The courier service may deliver the product to the client upon successful verification of the COD transaction by the issuing entity.
[082] Figure 5 shows a schematic of a server 506 to realize at least a portion of the payment network module 1 10 shown in Figure 1 . The server 506 facilitates conduct of a COD transaction and includes at least one processor 503 and at least one memory 507. Other components that the server 506 may have are omitted for the purposes of simplicity.
[083] The server 506 is in wireless communication with a mobile electronic device 502 that is used to facilitate the transaction. In an example implementation, the server 506 is in communication with the mobile electronic device 502 via an open connection message session 510. The open connection message session may use an unstructured supplementary services data (USSD) protocol.
[084] Computer program code within the at least one memory 507 is configured to have the at least one memory 507, with the at least one processor 503, cause the server 506 to at least: (i) assign a unique identifier to the COD transaction; (ii) receive the unique identifier during delivery; (iii) generate a transaction payment confirmation request upon receipt of the unique identifier; (iv) transmit the transaction payment confirmation request, using an open connection message session, to the mobile electronic device for transaction payment confirmation; (v) receive, from the mobile electronic device, a response to the transaction payment confirmation request during the open connection message session; and (vi) process the COD transaction based on the response to the transaction payment confirmation request.
[085] The server 506 may be further caused to: (vii) generate the unique identifier; and/or (viii) authenticate a user of the mobile electronic device, during the open connection message session, after receiving the response to the transaction payment confirmation request.
[086] Processing of the COD transaction may comprise verification of the COD transaction by an issuing entity that issues the payment instrument. The unique identifier is received from a courier service that is delivering a product to the user of the mobile electronic device. The courier service delivers the product to the user of the mobile electronic device upon successful verification of the COD transaction by the issuing entity.
[087] It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

1 . A method for conducting a cash-on-delivery (COD) transaction assigned a unique identifier by a server, the method comprising:
receiving the unique identifier during delivery;
generating a transaction payment confirmation request upon receipt of the unique identifier;
transmitting the transaction payment confirmation request, using an open connection message session, to a client for transaction payment confirmation;
receiving, from the client, a response to the transaction payment confirmation request during the open connection message session; and
processing the COD transaction based on the response of the client to the transaction payment confirmation request.
2. The method as claimed in claim 1 , wherein the open connection message session uses an unstructured supplementary services data (USSD) protocol.
3. The method as claimed in claim 1 or 2, further comprising generating, at the server, the unique identifier for the transaction.
4. The method as claimed in any one of the preceding claims, wherein the response of the client to the transaction payment confirmation request comprises a selection of a payment instrument for payment of the COD transaction.
5. The method as claimed in claim 4, wherein the payment instrument comprises a debit or credit card account.
6. The method as claimed in claim 4 or 5, further comprising authenticating the client, during the open connection message session, after receiving the client's response to the transaction payment confirmation request.
7. The method as claimed in claim 4 to 6, wherein processing of the COD transaction comprises verification of the COD transaction by an issuing entity that issues the payment instrument.
8. The method as claimed in claim 7, wherein the unique identifier is received from a courier service that undertakes the delivery.
9. The method as claimed in claim 8, wherein the courier service completes the delivery to the client upon successful verification of the COD transaction by the issuing entity.
10. A system for conducting a cash-on-delivery (COD) transaction, the system comprising a server in wireless communication with a mobile electronic device used to facilitate the transaction, the server comprising:
at least one processor; and
at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the server at least to:
assign a unique identifier to the COD transaction;
receive the unique identifier during delivery;
generate a transaction payment confirmation request upon receipt of the unique identifier;
transmit the transaction payment confirmation request, using an open connection message session, to the mobile electronic device for transaction payment confirmation;
receive, from the mobile electronic device, a response to the transaction payment confirmation request during the open connection message session; and
process the COD transaction based on the response to the transaction payment confirmation request.
1 1 . The system as claimed in claim 10, wherein the open connection message session uses an unstructured supplementary services data (USSD) protocol.
12. The system as claimed in claim 10 or 1 1 , wherein the server is further caused to generate the unique identifier.
13. The system as claimed in any one of the claims 10 to 12, wherein the response to the transaction payment confirmation request comprises a selection of a payment instrument for payment of the COD transaction.
14. The system as claimed in claim 13, wherein the payment instrument comprises a debit or credit card account.
15. The system as claimed in claim 13 or 14, wherein the server is further caused to authenticate a user of the mobile electronic device, during the open connection message session, after receiving the response to the transaction payment confirmation request.
16. The system as claimed in claim 15, wherein processing of the COD transaction comprises verification of the COD transaction by an issuing entity that issues the payment instrument.
17. The system as claimed in claim 16, wherein the unique identifier is received from a courier service that undertakes the delivery to the user of the mobile electronic device.
18. The system as claimed in claim 17, wherein the courier service completes the delivery to the user of the mobile electronic device upon successful verification of the COD transaction by the issuing entity.
EP15839168.0A 2014-09-12 2015-09-10 Method and system for conducting a cash-on-delivery (cod) transaction Withdrawn EP3192028A4 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN2631DE2014 2014-09-12
PCT/SG2015/050310 WO2016039692A1 (en) 2014-09-12 2015-09-10 Method and system for conducting a cash-on-delivery (cod) transaction

Publications (2)

Publication Number Publication Date
EP3192028A1 true EP3192028A1 (en) 2017-07-19
EP3192028A4 EP3192028A4 (en) 2018-02-21

Family

ID=55459338

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15839168.0A Withdrawn EP3192028A4 (en) 2014-09-12 2015-09-10 Method and system for conducting a cash-on-delivery (cod) transaction

Country Status (3)

Country Link
EP (1) EP3192028A4 (en)
SG (1) SG11201701625VA (en)
WO (1) WO2016039692A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200104792A1 (en) * 2018-10-01 2020-04-02 Glovoapp23 Sl Secure payment system and method for courier based transactions

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002024730A (en) * 2000-07-10 2002-01-25 Hitachi Ltd Electronic payment method and system by cellular phone
JP2002117355A (en) * 2000-08-03 2002-04-19 Network Solutions Kk Device, system and method for supporting account settlement
AU2001280125A1 (en) * 2000-08-24 2002-03-04 Jcb Co., Ltd. Card payment method and card payment system for door-to-door delivery
JP2003346067A (en) * 2002-05-24 2003-12-05 Ntt Docomo Inc Electronic settlement method, electronic settlement server device, and program

Also Published As

Publication number Publication date
SG11201701625VA (en) 2017-03-30
EP3192028A4 (en) 2018-02-21
WO2016039692A1 (en) 2016-03-17

Similar Documents

Publication Publication Date Title
US10902397B2 (en) Interoperable financial transactions via mobile devices
US10248952B2 (en) Automated account provisioning
US20180268404A1 (en) Remote variable authentication processing
US10832533B2 (en) Receipt processing and access service
US10922675B2 (en) Remote transaction system, method and point of sale terminal
US20150161597A1 (en) Transactions using temporary credential data
US20140310183A1 (en) Embedded acceptance system
US10664821B2 (en) Multi-mode payment systems and methods
US20150120472A1 (en) Digital wallet system and method
US11556929B2 (en) Method and corresponding proxy server, system, computer-readable storage medium and computer program
CA2994856C (en) Real-time authorization of initiated data exchanges based on tokenized data having limited temporal or geographic validity
US20150039506A1 (en) Methods and systems for providing 3-d secure service on-behalf-of merchants
US20110055076A1 (en) Response to alert message
US20170011440A1 (en) Online mobile payment using a server
US11023880B2 (en) Online mobile payment system and method using authentication codes
US20180144332A1 (en) Online mobile payment system and method using a server between the personal comuter and the mobile payment device
US11257063B2 (en) Telephone call purchase with payment using mobile payment device
US20160379210A1 (en) Method of conducting a transaction based on a code
WO2016039692A1 (en) Method and system for conducting a cash-on-delivery (cod) transaction
RU2530323C2 (en) Method for safe use of bank cards (versions)
AU2015249145B2 (en) Remote variable authentication processing
WO2014019026A1 (en) Electronic transction system and method
EA041883B1 (en) SYSTEM AND METHOD FOR CONDUCTING REMOTE TRANSACTIONS USING POINT OF SALE PAYMENT TERMINAL

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170221

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20180119

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/16 20120101AFI20180115BHEP

Ipc: G06Q 20/32 20120101ALI20180115BHEP

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: MASTERCARD ASIA/PACIFIC PTE. LTD.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200218

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200630