WO2021211054A1

WO2021211054A1 - A communication system and method for enabling payment to an offline payee using offline markers

Info

Publication number: WO2021211054A1
Application number: PCT/SG2020/050239
Authority: WO
Inventors: Le Mercier LEON EMIL; Wang HENRY; Catlin RICHARD JUSTIN
Original assignee: Slip Pay Technologies Pte. Ltd.
Priority date: 2020-04-16
Filing date: 2020-04-16
Publication date: 2021-10-21

Abstract

The present invention provides users with a communication method and system for enabling payment and/or information transfer to an entity using offline markers, for example, for authenticating a payment and submitting a request for settlement by a third-party payment processor. The method and system is configured to function where the entity being paid is not connected to any data network or power, and can be used to enable a payment process which is simple and secure.

Description

A COMMUNICATION SYSTEM AND METHOD FOR ENABLING PAYMENT TO AN OFFLINE PAYEE USING OFFLINE MARKERS

Field of the Invention

The present invention relates to a centralised and secure communication system in which a payer using a variety of non-cash payment methods is able to use a mobile device to identify and make payment to a payee, where the payee relies on an unpowered, unconnected unique identifier. Such a system is also amenable to transfer other types of valuable information between two users.

Background

Two of the biggest challenges facing small businesses today are (a) the acceleration towards cashless payments, and (b) the increasing need to acquire and harness data to retain customers. Whilst many systems do exist in isolation, they have to be delivered together in a system with the flexibility to fulfil both tasks in a cost effective, and robust manner.

The most common electronic payment method today involves a traditional point-of-sale (POS) devices which require continuous power and network connections. These devices typically act as an active device in a near field communication (NFC) payment relationship. However, these powered POS devices face usage constraints as they are typically only suitable for locations which provide mains power and a network connection. Correspondingly, such constraints compromise their suitability for ad-hoc payment needs in temporary or remote locations which typically lack mains power and connectivity to a landline internet connection.

Moreover, the typical POS device acts as an active device broadcasting payment details to the payment processing network. In this instance, where the payment involves a powered mobile device and a POS device, there is an inherent redundancy in the need for both devices to be powered and have network connectivity. Ultimately it is the POS device which reads and broadcasts payment information to be processed, which means that the payee must be in a permanent location which requires continuous power and network connectivity. As a result of the shortcomings from the use of powered POS devices, new processes are preferred. A mobile device is powered natively and can be configured to enable communication system protocols to identity and pay a payee by using offline unique markers. Meanwhile, smaller businesses, for example traditional brick and mortar retail or restaurants face increasing competition in a digitized age, where small businesses lack the ability of large chains to collect and analyse data on customers, leading to a disappearance of entities which lack access to such information or capabilities. Often, the data acquisition aspect is the most difficult, and should be done in a manner which is non-invasive while capturing the requisite consent.

A mobile first communication system which enables payments to offline payees, but also allows for information sharing is ideally suited to fulfill both tasks.

Summary

A secure communication and information transfer system operating in a centralised manner. The system allows for a Payer to transfer information including but not limited to, a payment intent, an offline Payee marker, or other forms of personally identifiable information in order to effectuate a financial or non-financial value transfer facilitated by a central processor amenable to identifying and processing such transfers.

The system itself can be communicatively coupled to any third-party payment processor to enable payment requests to be sent for settlement. As a result, the system itself possesses an extra security redundancy from the fact it does not hold any user funds.

In a first aspect, there is provided a communication system for enabling a payment to an offline Payee with a unique marker, the system including one or more data processors and a client configured to: initiate, at a Payer device, a request to pay; receive, at the Payer device, a Payee marker; compile, at the Payer device, an information packet for making the payment; verify, at the central processor, the information packet; identify, at the central processor, the Payee; compile, a payment request, at the central processor; and transmit, to a payment processor, the payment request.

Preferably, the Payee marker is offline.

In a second aspect, there is provided a data processor implemented communication method for enabling a payment to an offline Payee with a unique marker, the method comprising: initiating, at a Payer device, a request to pay; receiving, at Payer device, a Payee marker; compiling, at the Payer device, an information packet for making the payment; verifying, at the central processor, the information packet; identifying, at the central processor, the Payee; compiling, a payment request, at the central processor; and transmitting, to a payment processor, the payment request.

In a third aspect, there is provided a Payer device configured for enabling a payment to an offline Payee with a unique marker, the Payer device including one or more data processors configured to: initiate, a request to pay; receive, a Payee marker; compile, an information packet for making the payment; and transmit, to a central processor, the information packet.

In a final aspect, there is provided a central processor configured for enabling a payment to an offline Payee with a unique marker, the central processor including one or more data processors configured to: receive, from a Payer device, a request to pay; receive, from the Payer device, the information packet; verify, the information packet; identify, the Payee; compile, a payment request; and transmit, to a payment processor, the payment request. It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting. Brief Description of the Drawings

A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which: FIG 1A/B is a flow chart of an example of a communication method for enabling payment and or information transfer to an entity;

FIG 2 is a schematic diagram of an example of a communication system for enabling payment and/or information transfer to an entity;

FIG 3 is a schematic diagram showing components of an example user device of the system shown in FIG 2;

FIG 4 is a schematic diagram showing components of an example central processor shown in FIG 2; and

FIG 5 is a first example of Payee marker generation;

FIG 6 is a second example of Payee marker generation; FIG 7 A is a process flow of an example of a first token generation process for the method of FIG 1 ;

FIG 7B is an example of a JSON web token referred to in FIG 7 A; and FIG 8 is an example of a Payer device client.

Detailed Description

Embodiments of the present invention provide users with a communication method and system for enabling payment and or information transfer to an entity using offline markers, for example, for authenticating a payment and submitting a request for settlement by a third-party payment processor, whereby the payment is for provision of at least one good and/or carrying out of at least one service in a physical location (which can be a temporary set-up). The method and system are configured to function where the entity being paid is not connected to any data network or power source, and can be used to enable a payment process which is simple and secure. It should be appreciated that entity can relate to a natural person or a legal object like a company or business. In all instances in the following description, the entity is identified to ensure that payment is made to an appropriate payment repository associated with the entity for a good/service provided by the entity. It should be noted that payment can be in a form of, for example, fiat currency, fiat-backed stable-coins, native cryptocurrency, or any quantifiable payment instrument.

For the avoidance of doubt, some terms and their respective intended definitions which will be used in the description is provided as follows: Client: a user interface which can be accessed to send inputs and retrieve outputs from a central server/processor.

Payment Relationship: at least two entities who wish to transfer value between each other, where at least one is a Payer and at least one is a Payee.

Payer: an entity who transmits monetary value.

Payee: an entity who receives monetary value. Matched Payment: a confirmed payment driven by the initiation of the Payment Relationship that includes, for example, respective identities of each Payer(s) and Payee(s), the currency, amount of monetary value, Payer’s payment authorization as a result of processing at the central processor and so forth. Settlement: an act of realizing the transfer of electronic monetary value pursuant to the Matched Payment.

Offline: not requiring connectivity to a data network. An example of a broad overview of a communication method 100 for enabling payment and/or information transfer to an entity using offline unique markers will now be described with reference to FIG 1A and FIG IB. For the purpose of illustration, it is assumed that the method 100 can be performed at least in part using one or more data processing devices which form part of a Payer device, such as mobile phones, wearable devices, or the like. The Payer device is responsible for identifying the Payee and manages communication with a central processor. An entity device typically used by a Payee providing goods/services can be in the form of a wearable device that can be worn on for example the wrist. The entity device can also take other form factors and can be mounted to a structure, for example, a booth.

In this example, at step 103, the Payer selects an offline marker extraction option on the Payer device, as illustrated by the selector tab 810 on the Payer Client 800 on the Payer device shown in FIG 8. U sing the same input interface 800, at step 105, the Payer via the Payer device determines if there is a selection of an option to opt-in for Payer information disclosure to the Payee at check-box 820. If yes, step 107 initiates and records the consent to share Payer information by transmitting the consent data to the central processor, specifically the consent boolean registered at the Payer Client 800 to determine if the Payer's personally identifiable information should be shared. Subsequent to initiating consent, step 110 follows.

If the Payer does not opt-in to share Payer information, the method 100 proceeds directly to step 110, where the Payer via the Payer device Client initiates a request to pay for a good/service using the Payer Client. The request can include data to identify a specific good/service from a merchant, such as, for example, a serial/item number of a good/service, a merchant ID providing the good/service, a name of the good/service, a cost of a good/service any combination of the aforementioned, and so forth. It should be appreciated that prior to step 103, the Payer device receives a time-sensitive hash-based message authentication (HMAC) based token for use by the client during the method 100. Of course, other appropriate tokens can be used too. In addition, it should be appreciated that the Payer device only receives the HMAC based token upon successful login via the Payer Client.

At step 120, the one or more electronic processing devices of the Payer device receives a Payee marker via an offline marker extraction method shown for example on the selector tab 810, the Payee marker being for authenticating the Payee after processing at the centralised processor. For example, the Payee marker is obtained via a wireless signal transmitted from a passive entity device that can be worn or mounted to a structure. It should be appreciated that the entity device should be robust and does not require a native power source. Thus, NFC is a suitable wireless communication technology which can be used by the entity device as it has short range and can be activated by the Payer Device. It should be appreciated that the entity device is not powered and not coupled to any data network, so the entity device is not affected during instances of power/data network outages.

The Payee marker can be of an arbitrary length composed of characters from the alphanumeric set and should be unique for each Payee. The design of the marker should be such that, in plaintext it is easily readable and interpreted, being amenable to manual entry into a Payer device Client if necessary. Methods for generating unique markers broadly fall into two categories, one being to draw explicitly with or without replacement up to an arbitrary length from a specified selection set (e.g. alphanumeric) based on a specified discrete probability mass function; the other being the employment of collision- resistant cryptographic hash functions in a recursive construct starting from a random initial input. Further information for the entity device and the marker generation is provided in a subsequent portion of this description.

At step 130, the Payer device Client compiles an information packet comprising data of, for example, currency type, amount paid, Payee marker, the time sensitive HMAC signature token and so forth. This information packet is then transmitted via secure internet communication protocols (e.g. Transport Layer Security) to the central processor at step 140 for processing.

At step 150, the central processor processes the information packet sent by the Payer device Client, extracting the required information from the necessary fields for use in step 160. The HMAC based authentication token serves to identify and authenticate the Payer at step 160, whilst the offline marker serves to identify the Payee. The central processor then compiles a payment request, involving an information transfer composed of the Payer, Payee, currency and payment amount. At step 170, the one or more electronic processing devices of the central processor transmit the payment request to a third-party payment processor. The processing of the payment request is carried out independently. A final settlement of the payment request can take several days depending on the third- party payment processor. The central processor will receive a confirmation from the third-party payment processor that payment has been carried out in an appropriate manner. Once this confirmation is received, the central processor transmits details of the payment to the Payer device. The aforementioned confirmation is deemed by the central processor to mean payment finality and is broadcast back to Payer device Client at step 180. The confirmation shown on Payer device Client can be used to indicate an irrevocable payment between the Payer and the Payee. Finally, at step 190, Payer information is displayed on a Payee Client, only when it is determined that the Payer opted-in for information disclosure at step 105. Payment methods can be via debit card, credit card tokens or via EMV based third party payment wallets, such as, for example, Apple™ Pay, Google™ Pay, or the like.

Accordingly, the above described method provides a number of advantages. As described in preceding paragraphs, embodiments of the present invention aid in settlement of payments between Payer and Payee in temporary or remote locations without a sustained power connection, but where cellular or internet connections are available. The present invention offers the advantage that Payees can be offline and unpowered whilst still being able to receive payments. Furthermore, the invention enables Payees to reduce lost sales in situations where the Payer would have otherwise been required to pay in cash. Furthermore, it is also possible for the Payee to obtain Payer information whenever the Payer is willing to share that information with the Payee.

An example of a communication system 200 for enabling payment and/or information transfer to an entity using offline markers will now be described with reference to FIG 2.

In this example, the system 200 includes one or more entity devices 270, one or more Payer devices 220 running a Client responsive to receiving the HMAC token and for the Payer to enter payment details, a communications network 250, a central processor 260, and a third-party payment processor 240. The Payer devices 220 communicates with the Offline entity devices 270 via NFC. A unique offline marker is transmitted from the entity device 270 by the entity device first deriving power from electromagnetic induction induced by the Payer devices 220 and then transmitting data over radio frequency (RF) (for example, 13.56 MHz). The Payer devices 220 and the central processor 260 are in communication with each other via the communications network 250. In addition, the central processor 260 is also in communication with the third-party payment processor 240 via the communications network 250. The communications network 250 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs). Further details of respective components of the system 200 will be provided a following portion of the description. It will be appreciated that the configuration shown in FIG 2 is for the purpose of illustration only. Payer Device 220

The Payer device 220 of any of the examples herein may be a handheld computer device such as a smart phone with a capability to download and operate mobile applications, and be connectable to the communications network 250. An exemplary embodiment of the Payer device 220 is shown in FIG 3. As shown, the device 220 includes the following components in electronic communication via a bus 311:

1. a display 302;

2. non-volatile memory 303;

3. random access memory ("RAM") 304;

4. data processor(s) 301;

5. a transceiver component 305 that includes a transceiver(s);

6. an image capture module 310; and

7. input controls 307.

Although the components depicted in FIG 3 represent physical components, FIG 3 is not intended to be a hardware diagram; thus many of the components depicted in FIG 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG 3.

Central Processor 260

The central processor 260 is a hardware and software suite comprised of pre-programmed logic, algorithms and other means of processing information coming in, in order to send out information which is useful to the objective of the system in which the central processor 260 resides. For the sake of illustration, hardware which can be used by the central processor 260 will be described briefly herein. The central processor 260 can broadly comprise a database (relational or non-relational) which stores Payer and Payee information, processes information packets from clients and communicates with third- party payment processors. The central processor 260 can generate and store security tokens, determine the identity of a Payee, and compile requisite payment information for payments to be processed by a third-party payment processor. The central processor 260 can be administered by the authentication organisation or run from a commercial hosted service such as Amazon Web Services ™. The central processor 260 may be underpinned by any suitable processing device, and one such suitable device 400 is shown in FIG 4.

In this example, the device 400 is in communication with a communications network 250, as shown in FIG 4. The device 400 is able to communicate with the Payer devices 220, the payment processor 240, and/or other processing devices, as required, over a communications network 250 or directly with the respective devices.

The components of the central processor 260 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 250 for communication.

In the example shown in FIG 4, the device 400 is a commercially available computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the device 400 are implemented in the form of programming instructions of one or more software components or modules 402 stored on non-volatile (e.g. , hard disk) computer-readable storage 403 associated with the central processor 260.

The device 400 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 405 :

1. random access memory (RAM) 406; and

2. at least one central processing unit (CPU) 407 Payment Processor 240

A suitable payment processor 240 for use in the system 200 described in any of the above examples is administered by a third-party payment processing organisation. It should be appreciated that the payment processor 240 as shown can also be known as a payment module with tasks executed on at least one server. The third-party payment processor is independent and is responsible for the settlement of payments. Entity Device 270

The entity device 270 of any of the examples herein may be a wearable or mountable device. It can be for example worn on a wrist. The device can also take other form factors and be mounted to a structure, for example, a booth, and the like. The entity device 270 does not have a power source, is structurally robust, and can be manufactured at a low cost. The entity device 270 includes a passive NFC tag that derives power by electromagnetic induction from a powered Payer device 220 when the Payer device 220 is positioned at close proximity to the entity device 270. The NFC tag includes memory that is configured to be written to and read. However, once the text-based data (offline unique marker) is written to the memory, the tag is locked and configured to be read-only.

Further details will now be provided for various aspects of the method 100 and the system 200.

Payee Unique Marker The Payee marker can be a unique offline marker embedded on a passive NFC tag of the entity device 270 to identify a Payee. It should be appreciated that there can be other offline markers used to identify a Payee. The unique offline marker is transmitted from the entity device 270 by the entity device first deriving power from electromagnetic induction induced by the Payer device and then transmitting data over RF (for example, 13.56 MHz), as shown in FIG 2.

The unique marker is a piece of data associated and tagged to a specific Payee. One embodiment of the marker generation could be via drawing characters with or without replacement from a selection set based on a defined discrete probability mass function. An illustration of this algorithm is shown in FIG 5.

Another embodiment of the marker generation is shown in FIG 6 where a collision resistant cryptographic hash function (e.g. SHA256 or ripemd) is initialised with a random input. A random positive integer (L) is chosen from a discrete probability mass function, which determines the number of iterations in the recursive hash function. The recursive hash function is initialised by feeding the random input into the specified hash function. This output is then fed into hash function and ran through L-l recursions. Note that the hash output at each iteration is encoded from binary into the base representation chosen for the run, this could be for example a hexadecimal representation.

Token Generation

Reference is made to FIG 7 A to illustrate a possible embodiment for a token generation process 700 for the Payer device 220 used in the method 100 and the system 200. FIG 7A illustrates the exchanges between the Payer device 220 and the central processor 260 (as labelled in FIG 2). However, it should be appreciated that there can be other token generation processes being used other than that as described in the subsequent paragraphs.

As the token generation process is only carried out after the Payer has logged into the authentication/payment application installed on the Payer device 220 (not necessarily using the process as described in the preceding paragraphs), it should be appreciated that the Payer device 220 and the central processor 260 are connected with a transport layer security (TLS) connection.

After the Payer is logged in at the authentication/payment application in the Payer device 220, at step 710, the central processor 260 generates and stores a JSON web token associated with the Payer and transmits the JSON web token to the Payer device Client 220. An example of the JSON web token is shown in FIG 7B. Broadly, the JSON web token comprises a header, body and signature. The signature is generated via an HMAC signature scheme with a defined cryptographic hash function and is unique to the body in the web token. The additional data stored in the web token is a JWT token.

In the absence of a TLS connection, it would be possible for a third party to intercept the token and thereby grant itself access to divert payments to an illicit account. If the attacker possessed the token, they could either: A) Pass an unauthorized payment request with the token, currency, amount, and a unique marker associated with a malicious/unauthorised account. As the payment amount and currency are not embedded in the JWT body and signed for, the JWT need not be tampered; or B) Intercept traffic to the central processor and insert the unique marker associated with a malicious account, thereby diverting the payment intent to a third party.

During a typical “man-in-the -middle” hacking attempt, if the body of the web token is intercepted and modified, the signature no longer matches the body in the web token, and this body-signature mismatch leads to a rejection of the web token at the central processor 260.

At step 720, once the Client compiles and transmits an information packet, that is, steps 130 and 140 of FIG 1 , the web token, payment amount and unique marker are sent in plaintext from the Payer device 220 to the central processor 260. The central processor 260 then checks the signature of the web token to confirm that the Payer is correct, and also checks on the validity of the web token. As such, step 720 involves authenticating the Payer.

Offline Marker Alternatives

In some embodiments, the entity device 270 may be instead a static visual image or other offline platforms which carry biometric information (i.e. the human hand). These other variations of the entity device which hosts other forms of offline unique markers are responsive to being read by the Payer Device 220 using the camera module 310.

In one embodiment, the Payer device 220 can, using the camera module 310, be used to capture visual indicia with embedded data (derived from aforementioned unique marker), like quick response matrices to obtain Payee unique markers. In other embodiments the Payer device 220 can, using the camera module 310, be used to capture images to obtain biometric information. The biometric information can be obtained/derived from, for example, retina images, fingerprint images, facial images, and the like. In these embodiments, the Payer device Client 220 pushes the biometric information to the central processor, where it is matched against pre-set biometric markers for the Payee. The biometric marker here provides the same purpose as the Payee markers transmitted wirelessly by the entity device 270, when the entity device is an offline NFC tag.

Possible Variations The invention described in the method 100 and system 200 relate to a fundamental single Payer to single Payee scenario. It should be appreciated that the invention can be applied in multi-party scenarios. Possible non-limiting scenarios include, for example:

A) Single Payer, plurality of Payees: It is envisaged that this can be carried out when the Payer device 220 is able to receive the Payee markers of the respective Payees.

B) Plurality of Payers, single Payee: It is envisaged that each respective Payer device 220 or a master Payer device 220 is able to apportion payment, whereby each Payer device 220 or the master Payer device 220 is able to receive the Payee marker of the respective Payees.

Advantages The invention described in the the method 100 and system 200 enable benefits that would not otherwise be available. They are: i. Convenience for the Payer during payment; ii. Zero power and data network requirements for the Payee, correspondingly enabling the Payee to receive electronic payments in a wider variety of locations; iii. Robust and reliable payment process for all parties; iv. Scalable solution for payment; and v. Avoided loss of sale of goods/service for Payee, in situations where Payer may not have (a) access to cash or (b) enough cash to transact

Throughout this specification and claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A communication system for enabling a payment to an offline Payee with a unique marker, the system including one or more data processors and a client configured to: initiate, at a Payer device, a request to pay; receive, at the Payer device, a Payee marker; compile, at the Payer device, an information packet for making the payment; verify, at the central processor, the information packet; identify, at the central processor, the Payee; compile, at the central processor, a payment request; and transmit, to a payment processor, the payment request, wherein the Payee marker is offline.

2. The system of claim 1, further configured to: receive, at the Payer device, a time-sensitive token for use in authenticating the Payer information packet.

3. The system of either claim 1 or 2, further configured to: determine, at the Payer device, if Payer information should be disclosed to the Payee.

4. The system of any of claims 2 to 3, wherein the information packet includes data selected from a group consisting of: currency, amount paid, Payee marker, and the time-sensitive token.

5. The system of any of claims 1 to 4, wherein the offline Payee marker is obtained from an entity device.

6. The system of any of claims 1 to 4, wherein the offline Payee marker is obtained from image- derived biometric information.

7. The system of any of claims 1 to 4, wherein the offline Payee marker is obtained from captured visual indicia.

8. A data processor implemented communication method for enabling a payment to an offline Payee with a unique marker, the method comprising: initiating, at a Payer device, a request to pay; receiving, at Payer device, a Payee marker; compiling, at the Payer device, an information packet for making the payment; verifying, at the central processor, the information packet; identifying, at the central processor, the Payee; compiling, at the central processor, a payment request; and transmitting, to a payment processor, the payment request, wherein the Payee marker is offline.

9. The method of claim 8, further comprising: receiving, at the Payer device, a time-sensitive token for use in authenticating the Payer information packet

10. The method of either claim 8 or 9, further comprising: determining, at the Payer device, if Payer information should be disclosed to the Payee.

11. The method of any of claims 9 to 10, wherein the information packet includes data selected from a group consisting of: currency, amount paid, Payee marker, and the time-sensitive token.

12. The method of any of claims 8 to 11, wherein the offline Payee marker is obtained from an entity device.

13. The method of any of claims 8 to 11, wherein the offline Payee marker is obtained from image- derived biometric information.

14. The method of any of claims 8 to 11, wherein the offline Payee marker is obtained from captured visual indicia.

15. A Payer device configured for enabling a payment to an offline Payee with a unique marker, the Payer device including one or more data processors configured to: initiate, a request to pay; receive, a Payee marker; compile, an information packet for making the payment; and transmit, to a central processor, the information packet, wherein the Payee marker is offline.

16. The Payer device of claim 15, further configured to receive, a time-sensitive token for use in authenticating the Payer information packet.

17. The Payer device of either claim 15 or 16, further configured to determine, if the Payer information should be disclosed to the Payee.

18. The Payer device of any of claims 16 to 17, wherein the information packet includes data selected from a group consisting of: currency, amount paid, payee marker, and the time-sensitive token.

19. The Payer device of any of claims 15 to 18, wherein the offline Payee marker is obtained from an entity device.

20. The Payer device of any of claims 15 to 18, wherein the offline Payee identifier is obtained from image-derived biometric information.

21. The Payer device of any of claims 15 to 18, wherein the offline Payee identifier is obtained from captured visual indicia.

22. A central processor configured for enabling a payment to an offline Payee with a unique marker, the central processor including one or more data processors configured to: receive, from a Payer device, a request to pay; receive, from the Payer device, the information packet; verify, the information packet; identify, the Payee; compile, a payment request; and transmit, to a payment processor, the payment request, wherein the Payee marker is offline.

23. The central processor of claim 22, further configured to: transmit, to the Payer device, a time-sensitive token for authenticating the information packet.

24. The central processor of either claim 22 or 23, further configured to: receive, from the Payer device, consent data to determine if Payer information should be disclosed to the Payee.

25. The central processor of either claim 23 or 24, wherein the information packet includes data selected from a group consisting of: currency, amount paid, payee marker, and the time-sensitive token.

26. The central processor of any of claims 22 to 25, wherein the offline Payee marker is obtained from an entity device.

27. The central processor of any of claims 22 to 25, wherein the offline Payee marker is obtained from image-derived biometric information.

28. The central processor of any of claims 22 to 25, wherein the offline Payee marker is obtained from captured visual indicia.