GB2466038A - Authorisation of cashless payment using SMS - Google Patents
Authorisation of cashless payment using SMS Download PDFInfo
- Publication number
- GB2466038A GB2466038A GB0822386A GB0822386A GB2466038A GB 2466038 A GB2466038 A GB 2466038A GB 0822386 A GB0822386 A GB 0822386A GB 0822386 A GB0822386 A GB 0822386A GB 2466038 A GB2466038 A GB 2466038A
- Authority
- GB
- United Kingdom
- Prior art keywords
- mobile wallet
- merchant
- customer
- virtual money
- money system
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/0036—Checkout procedures
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Mobile Wallet materialises the whole concept of having a virtual wallet. Never again will a person have to depend on carrying their credit cards or cash on them at all times when purchasing products from a shop or online. Mobile Wallet eliminates the necessity and need for physical cash or credit cards to be used on a day to day basis whilst shopping. Mobile Wallet facilitates a safer way to go shopping as there will be no risk of losing cash/cards or even have them stolen, since you will no longer have to carry them with you. Using their mobile phones, people will be able to 'virtually pay' for whatever goods/products they wish to buy. Whether its clothes, electronics, food, airline tickets, whatever, customers will be able to automatically send the amount payable to the merchant instantly and securely without the need to physically hand over cash, or the need to enter secure information (such as a signature or credit card pin number) in front of the merchant.
Description
Mobile Wallet Mobile Wallet eliminates the necessity and need for physical cash or credit cards to be used on a day to day basis whilst shopping. Mobile Wallet facilitates a safer way to go shopping as there will be no risk of losing cash/cards or even have them stolen, since you will no longer have to carry them with you.
Using their mobile phones, people will be able to virtually pay' for whatever goods/products they wish to buy. Whether its clothes, elecfronics, food, airline tickets, whatever, customers will be able to automatically send the amount payable to the merchant instantly and securely without the need to physically hand over cash, or the need to enter secure infomiation (such as a signature or credit card pin number) in front of the merchant.
Mobile Wallet would work via communication between the customer's mobile phone and the Mobile Wallet software application via the use of SMS technology. The Mobile Wallet application which would be level 1 PCI compliant would in turn communicate with a variety of payment.solutions and credit card acquirers allowing the user to deposit/withdraw money into Their virtual mobile wallet, which they would then use whilst shopping. The Mobile Wallet application would facilitate the transfers of monies between the customer and the merchant.
Figure 1 illustrates the flow of a transaction between the user, the merchant and the Mobile Wallet sofiware.
Below is a step by step description of Figure 1:
1. The customer goes to a shop which belongs to the Mobile Wallet schema and the retailer sends a request for the amount due for the products the customer wants to buy along with a receipt number which corresponds to the purchase and the unique account Id.
2. Via the account id, the Mobile Wallet server is able to identify the customer making the purchase. The Mobile Wallet server then sends a confirmation to the customer's mobile which the customer has to reply to within 60 seconds with their secure password. (if the customer does not reply within 60 seconds, the transaction is void, and step I in Figure 1 has to be repeated) 3. The customer sends the confirmation SMS which has his/her secure password included.
4. Mobile Wallet server checks to see if the user has enough funds in his/her wallet, if not then it rejects the transaction.
5. Mobile Wallet server sends the amount to the merchant.
6. Mobile Wallet sends a confirmation of a successful or erroneous transaction along with a transaction id to the merchant which they would receive instantly.
Customer Functionality Customers would need to sign up with Mobile Wallet. A simple one page registration process would be needed to ensure that the user can have access as quick as possible to the full range of features offered by Mobile Wallet.
The following essential information would be required by the user: * First name * Surname * Email * Mobile Phone Number Mobile Phone IMEI * Password * Address * Country * Secure Transaction Password1 * Choose to receive SMS and or MMS messages * Choose to receive alerts regarding different categories Mobile Wallet keeps a record of which merchants the customer has requested information from or purchased items from, which merchants they have opted out from, what codes they have accessed, how many times, what time of day and what days you accessed them.
This information would be available to the user through their personal Mobile Wallet account so that they may manage their account effectively.
For every merchant that the customer opts in to, a history of their requests identified by their unique 6 character user code (which is created automatically upon registration) Wilt be stored in the specific merchants account. The specific information that will be stored is as follows: * Customer's unique 6 character identifier code * Promotion codes and transactions requested * The number of times a code or particular merchant has been requested * Complete detail of each transaction, including date, time, amount etc 1 This secure password would be required when sending the confirmation SMS as shown in fIg 1 step 3.
To ensure security all of the information entered by the user would be processed. via https and oil passwords would be stored in the Mobile Wallet database using hashing technology, so only the customer would know what his/her password is. Not even Mobile Wallet personnel would have access to the customer's password. The customer's mobile number will NEVER be revealed to any merchant. The customer's mobile number is linked to a public 6 digit account Id which is the only thing the merchant sees. This account id is unique to each customer.
Mobile Wallet values customer privacy. Whenever a customer sends a code to Mobile Wallet, their request is logged so that the merchants (the retailers who have set the codes up) can see who has been using them. However, Mobile Wallet NEVER let these people see the customer's mobile number. Why? Well we think that it would be a massive invasion of privacy for anyone to call you up just because you've requested information via our system.
It is possible for merchants to send customers follow-up text messages through the Mobile Wallet system. This allows merchants to see if any customers have shown interest in their products, if may subsequently be reduced in price and that may be of interest to the customer.
Customers would register for tree with Mobile Wallet, and would have immediate access to the full history of codes they've sent in to the Mobile Wallet system. They would be able to see when they made a request and which code they used or what they purchased. The most important feature is that customers can choose to opt-out' of receiving further messages for one, a few or ALL of the promotion codes and/or merchants they have ever used. If a merchant is sending lots of text messages to a customer because they once enquired about one of their products or purchased something from them, the customer would simply log on to the system and opt-out of that code/merchant, it's as simple as that.
Customers will also be able to opt-in' to register your interest in receiving news, offers or surveys via SMS by sending a SMS to Mobile Wallet with the promotion code created by the merchant.
Mobile Wallet would ensure that the customer's mobile number is secure at all times.
Once the customer has an account created, they would have an array of features available to them: * Deposit * Withdraw * See history of statements (along with full details of each individual transaction, time/date, amount, shop, transaction id efc) * Block merchants from sending adverts2 * Edit detas * Send SMS to another Mobile Wallet user (to do this the customer would have to purchase Mobile Wallet SMS credits. These credits would be cheaper than sending a normal SMS via the customer's mobile phone simply because Mobile Wallet would have bulk messaging deals with a mobile network) * Send bulk SMS to other Mobile Wallet users 2 would only be able to send adverts/promos to users who have purchased from their shop * Transfer money to another Mobile Wallet user3 * Report mobile as stolen * Block account Both users would need to have an account with status of verified for this feature to be available Reporting Mobile Stolen Functionality: In the unfortunate event that a user loses or has their mobile stolen, Mobile Wallet offers the ability to report this: incidence and blocking the users Mobile Wallet account. The customer con block their account by going online and reporting their mobile as stolen/lost or they can call a free number and have their account blocked. The benefits of having this functionality are priceless. 14ot only does it insure the customer that their Mobile Wallet account and money are kept safe until they can unblock the account but it also gives an extra sense of security to the customer.
As an added security feature, if someone were to use the customer's stolen mobile to purchase something via Mobile Wallet or if someone tries to purchase online using this blocked account, Mobile Wallet will automatically alert the merchant that the phone has been stolen, and that it should be retained if possible. If the purchase was affempted in a physical shop (as opposed to online). Mobile Wallet would know exactly where it happened.
in what shop, what country, what street and even what exact cashier in the shop it happened. The Mobile Wallet customer would be alerted immediately so that they can recover their phone.
Entering Secure Password to Validate Purchase: As you can see from step 3 in Figure 1, the customer is requested to confirm the transaction by entering the secure password and sending it back to Mobile Wallet Generally this would not be considered secure because most mobile phones store sent messages in a sent items folder. Although This maybe a handy feature for the customer so that they don't hove to retype their password every time they need to authorise a transaction, it's considered as a security risk. If someone steals your mobile and you don't have time to block your account, they can immediately authorise a transaclion by going into your sent items and seeing your password.
Thus, Mobile Wallet will never ask the customer to send their full secure password. Instead Mobile Wallet will request different characters of their secure password at random. For example, Mobile Wallet will request the first and fifth characters, or the second and forth, etc. Customers will be asked to create a secure password upon registration which should be no less than 8 characters and must contain numbers and letters. This sort of functionality has been proved to work in the past by online banks and online credit card accounts.
Entering Account Id at Retailer In step 1 of Figure 1, the retailer has to send Mobile Wallet the unique account Id which identifies the customer making the purchase. For security and privacy reasons this account id should not be given out loud by the customer, instead the retailer should provide a numeric keypad (similar to those currently used to enter credit card pins) so that the customer can enter their account Id. This insures that no one can see or hear the customer unique account id. Although It is worth remembering that this account Id is useless without its corresponding phone and secure password! Receiving Category Alerts: Upon registration customers will be given the option to receive advert alerts regarding different categories (such as music, film, games. etc) or from different shops. These would be free for the customer to receive4. This is a great opportunity for merchants to reach many customers via directed advertising whether they have purchased products from their shops or not. Obviously customers have the ability to stop receiving these messages whenever they want.
Merchant Functionality Reporting Tools: Merchants who sign up to the Mobile Wallet scheme would have a very powerful marketing and reporting tool at the tip of their fingers. Using the Mobile Wallet tools, merchants would have access to a full report of all the. customers that have purchased merchandise from their shops and those who have registered their interest. This information can be further broken down into region. time, date and even product information.5 Every detail of the fransaction will be stored by Mobile Wallet. thus making the reporting tools incredibly powerful.
Mobile Wallet Codes: Merchants would have the ability to create Mobile Wallet codes which can be used by customers for a variety of functions such as to obtain discounts, acquire product information or participate in a scheme or even competition.
* Mobile Wallet codes for discounts: These codes would be sent by the customer when they send the first SMS as illustrated in figure 1, step 1.
* Mobile Wallet can also be set up to promote products: Merchants would create a promotion code and assign a description for it: Customers would then send a SMS to Mobile Wallet which includes the promotion code, Mobile Wallet would send the customer the information created by the merchant which corresponds to the promotion code. This can help the merchant hugely when gathering information regarding product interest which would in turn allow for directed advertising.
* Mobile Wallet code for schemes: Many merchants create schemes or even competitions which require customers to register. Using Mobile Wallet merchants are able to individually target certain customers which meet the promotion requirements.
* Mobile Wallet codes for reservation of products Merchants can also create promotion codes to be used for the reservation of a product, or to gather the interest of a new product. For example, if a merchant has a product which is to be released soon, they could set up a marketing campaign and attach a promotion code to it.
Customers could send this code to register their interest in the product. or to make a reservation. Merchants could run reports to see how many customers have registered their interest, thus seeing how popular the new product will be, even before it's sold.
Gold Codes' are useful for merchants who need to have a particular sequence of codes reserved for future use. For example, if you had a music shop then you may have a coding Unless they choose to receive MMS alerts in which case their network provider will charge them 5This would be possible by linking the transaction id with the merchant's receipt id.
system in use already that uses, say, ROCK' as a prefix to all of your internal code numbers to identify music which are classified as rock genre. You would then possibly have ROCKi', ROCK2', ROCK3' and so on to identity your different albums or sections.6 If a merchant using Mobile Wallet started typing in the codes, then they might find that someone else has already used ROCK2O' as a code for something else, which would throw your system into disarray.
The solution to this problem is to get a gold code' reserved. A gold code' consists of 4 or 3 alphabetic letfers followed by any number, as shown in the example (LEI 12, ROCK2 1, JAZZ 12) above. Once the merchant has been allocated a gold code', it is theirs as long as they are a Mobile Wallet customer meaning that no-one else can use any of your codes. Merchants would be able to reserve as many Gold Codes' as they like. Gold Codes' would be purchased by the merchant on a bulk basis.
Directed Advertising: One of the most powerful and unique tools of the Mobile Wallet for the merchant is directed advertising. Merchants will have the ability to uniquely target specific customers based on region, average amount spent by customer, promotion code used and product purchased.
By running a report to see how many customers have purchased a particular product the merchant can then send out bulk SMS or MMS to all the customers returned by the report to promote a similar product.
For example, a merchant that sells Music CD's might run a report to see how many customers purchased a particular artist's album or music genre. If that artist is about to release another album, the merchant could message those entire customers, thus ensuring directed advertising. Alternatively the merchant could simply bulk message all of their customers with general information regarding their products.7 Mobile Sales: Mobile Wallet offers a unique method for a merchant to sell goods without the need to transfers physical money or the need to take any other method of physical payments such as credit cards. By using Mobile Wallet, merchants do not need to worry about fraud or charge backs since this would be covered by the Mobile Wallet payments module. Since Mobile Wallet would be 100% PCI compliant, it means that merchants have one less major expense to worry about when processing transactions. This also makes customers feel much more in control and safer when purchasing goods since they no longer have to carry physical cash or cards with them and they no longer have to give away sensitive information to merchants such as credit card numbers, signatures etc. Setting up Mobile Wallet on a merchant's shop would be quick and relatively cheap.
Merchants would initially pay an integration fee as a Mobile Wallet merchant user. Once their account has been created the merchant who owns a physical shop would simply have to order a number of mobile phones, one for each till in their shop.
6 Merchants would have the ability to upload bulk codes via a csv file if needed.
It is important to note that customers will always have the ability to block merchants from messaging them.
Since each till would have its own mobile and unique mobile phone number, when a request is received by Mobile Wallet (as shown in figure 1, step 1), Mobile Wallet knows exactly what merchant the request came from and what till it corresponds to. Thus allowing reconciliation between Mobile Wallet and the merchant.
Merchants could also send MMS messages to their top customers which contains a bar code. This bar code would be scanned at the till and could be redeemed for discounts.
Merchants could also use MMS for advertising purposes such as for sending photos of their latest articles, videos, etc. The possibilities are limitless.
Advanced Customer Checkout Merchants could also opt for an Advanced Customer Checkout8 method which allows customers to checkout from the shop via the scanning of a barcode which links the customer to the current shop and transaction. This method would increase the speed in which a customer takes to checkout from a shop. Essentially the way this would work is as follows: L The customer walks into a shop which has Advanced Customer Checkout' enabled and he sends a SMS requesting to log on to the shop9 2. Mobile Wallet responds with a confirmation SMS that the user has to respond to within seconds to confirm that they are who they claim they are by sending their secure password.
3. Customer sends confirmation SMS.
4. Mobile Wallet responds with a MMS which contains a unique barcode that identifies the customer 5. Once the customer has finished purchasing the products, the cashier would simply scan the barcode which was sent to the customer's phone and the amount due would be automatically withdrawn from the customer's account and transferred to the merchant.
Although this method is slightly more expensive for the customer to use, because they have to send the standard confirmation SMS messages and then receive a MMS message, it ensures a much faster checkout, more secure and also provides a much more detailed transaction report/history in their account. For the merchant it would also be a preferred method of checkout since if automatically links the transaction with the full detail of the order, without the need to manually map the products purchased by a customer based on the transaction and receipt Id.
Limitations would exist with this method though since not every user will have MMS enabled phones, and not all merchants will want to modify their current system to allow integration info Mobile Wallet. This would incur a higher integration cost, longer period of integration and possibly hardware changes to their current setup. However for big retailers the benefits gained from this method would surely outweigh the costs, since the transactions would be fully detailed in ferrns of individual items purchased. price, etc. Thus allowing for a more elaborate and accurate use of directed advertising. Also for merchants who require rapid checkouts based on barcodes (such as Argos) this method would be ideal.
8This method would require the merchant to fully integrate their system into Mobile Wallet 50 that transactions can be fully detailed Mobile Wallet would incur the cost of this SMS who would then charge the merchant not the user Online Mobile Wallet Sales: Mobile Wallet could also be used for online purchasing. Online purchasing using Mobile Wallet gives the customer a more secure and safer method for purchasing products online.
Customers will no longer have to enter their payment details or personal information online when purchasing from an online shop. It will also reduce the amount of phising scams which revolve around online payments. Merchants will equally benefit from using Mobile Wallet for their online payments. Using online Mobile Wallet payments ensures for less fraud, less charge backs to merchants and less accounts being hacked. Online Mobile Wallet sales enable quick and easy online purchasing as well as remote purchasing without physically being in front of a PC. For example, a university student may need to buy something online, whilst the student completes the purchase online, he can use his parent's Mobile Wallet account id. This means his parents will receive a confirmation message with the transaction id and amount of the purchase, which they would then confirm.'° The following describes Figure 2: 1. The customer makes an order on an online shop which offers Mobile Wallet as a payment option. When the customer has clicked on the checkout button, and selected Mobile Wallet as a payment option, the website would ask the user for their unique Mobile Wallet account Id.
2. The online merchant would then show an order being processed page' to the customer whilst in the background they make a request to Mobile Wallet' 1, sending the account id and their own unique transaction Id with status set to pending.
3. Via the account Id, the Mobile Wallet server is able to identify the customer making the purchase. The Mobile Wallet server then sends a confirmation to the customer's mobile which the customer has to reply to within 60 seconds with their secure password. (if the customer does not reply within 60 seconds, the transaction is void, and step! has to be repeated) 4. The customer sends the confirmation SMS which has his/her secure password included.
5. Mobile Wallet checks the user has enough money in their account and sends the response to the merchant, setting the order status to either confirmed, success or failure response.
6. The website shows the user the order complete page. showing if the transaction has been either successful or if it failed.
means you would no longer have to give you credit cord details online or over the phone and a family member or friend can request a transaction which you then confirm or not.
1 This call could be made via a SMS or an online API call, whatever the merchant chooses.
How to Integrate into Mobile Wallet (API integration): There will be 2 API methods of integration into the Mobile Wallet platform that the merchant can choose from.
* Method 1 -simple': This method would require no integration between the merchant's system and Mobile Wallet. Mobile Wallet and the merchant would simply communicate via the use of SMS messages. The merchant would reconcile their transactions via the Mobile Wallet back office. Every SMS sent by the merchant would contain a receipt Id and Mobile Wallet would respond with a unique transaction Id.
This is what the merchant would use to reconcile. Via the back office, the merchant would be able to add detail to each transaction if they want to, thus improving their report details and directed advertising techniques. This method would be recommended for small merchants who do not require complex or detailed reconciliOtion between Mobile Wallet transactions and their own.
* Method 2 -detailed': This method of integration requires the merchant to fully integrate via an API into the Mobile Wallet platform. A number of https calls would be made between the merchant and Mobile Wallet (these calls would be established in step 1 of the flow as shown in Figure 1 and 2): 1. First the merchant would make a call to Mobile Wallet requesting a unique session token.
2. Mobile Wallet responds with a unique token which is then used by the merchant in the following requests thereafter.
3. The merchant sends the full details of the transaction, including a unique receipt id, items purchased, amount due, currency, unique account Id (given by customer) and the unique token provided in step 2.
4. Mobile Wallet would then send the confirmation message to the customer (as shown in figure 1 and 2, step 3).
Although method 2 requires more work from the merchant's point of view, it is the preferred and method that Mobile Wallet recommends. This method allows the merchant to have a fully detailed transactional history in the Mobile Wallet back office. It would be up to the merchant's discretion to use either method, and even if they use method 2, they would select the specific data they want to send Mobile Wallet when requesting a transaction.
However, the more accurate and detailed information the merchant sends the more intrinsic and useful their Mobile Wallet reports will be and the more accurately they will be able to use the directed advertising functionality.
Figure 3 is a domain model showing how the different software components with in Mobile Wallet would be linked with each other, thus forming Mobile Wallet as a whole.
The Mobile Wallet payment system module shown in Figure 3 is essentially a MPSP12. Mobile Wallet would be an e-wallet which is connected to a selection of the most popular online payment methods available, including credit card processing. It would essentially be linked to a library of payment solution APIs which allow the customer to deposit money into their Mobile Wallet account. The Mobile Wallet payment module would allow for instant payments, secure transactions and no charge backs for merchants. Mobile Wallet would 12 Payment Solution Provider enforce KYC and would have deposit limits for new accounts forcing customers to verify their accounts once transactions reach a certain limit such as �500 or so. Doing so means Mobile Wallet can guarantee the merchant that they will incur no charge backs when a customer purchases using Mobile Wallet. This in turn drastically reduces fraud for the merchant.
Security: Security tools and processes would be enforced by Mobile Wallet to guarantee the merchant a fraud free processing environment. This would be achieved via the Mobile Wallet back office which would include a suit of security fools which would offer real time monitoring of transactions.
Country and Currency features: Since the Mobile Wallet payment module would be connected to so many payment solutions which in turn offer many other payment solutions, merchants are suddenly given the opportunity to receive payrnerts from customers all over the world, in literally any currency which would have never been offered by the merchant to begin with. Dynamic Currency Conversion14 would also be offered by Mobile Wallet. This allows a customer from any country, using any currency make a purchase anywhere in the world, regardless of the currency or country of the merchant. By offering this functionality, the merchant suddenly increases its sources of revenue by at least 30%.
Probably one of the most important and attractive aspects of Mobile Wallet is that it will be 100% PCI compliant. Being PCI compliant for a merchant can equate to a lot of time and expenses which is not something any merchant wants to go through. Mobile Wallet will be simple to integrate and will offer immediate PCI compliance for all credit card transactions as well as all of the above.
Mobile Wallet would be completely FSA authotised to issue/handle electronic money' as 13 Know Your Client -Mobile Wallet would request the user for personal information such as copy of passport for security purposes to verify who they are Mobile Wallet would have a EX charge on this conversion based on FX values which would be updated daily Mobile Wallet Additional Notes Notes: * If is important to note that ANY mobile phone would work with Mobile Wallet. No matter how old or new the mobile is, as long as if can send/receive SMS messages if will work with Mobile Wallet. Obviously the advanced use of MMS messages are restricted to phones which altow for this feature.
* Merchants can upload the full detail of the purchase (receipt) to the Mobile Wallet server fagged with the transaction id sent to them via the confirmation message. The transaction id sent by Mobile Wallet would be Unked to the receipt number sent by the first message sent (as shown in figure L step I). The Mobile Wallet back office would show which transactions correspond to each receipt of the merchant. Doing this gives the user more data and information to run better detailed reporfs. If they chose to integrate into Mobile Wallet via method 2 of the API then this would not be necessary.
* Figure 3 illustrates how Mobile Wallet customers will also have the ability to transfer money between themselves. This would be done in a very simple way, similar to when they purchase something from a merchant.
* One important dependency which the Mobile Wallet platform has is the mobile phone network provider (e.g. Vodaf one, Orange, etc). Networks can get extremely busy and can even go down at certain times of the year. Thus the Mobile Wallet system will store every message received and every message it has to send in a stack.
Once the message has been sent and the transaction has been completed, the message will be removed from the stack, and ifs order status will be changed to complete. This is done in case the network goes down, it ensures transactions are not sent twice and that messages are always sent by Mobile Wallet.
Claims (16)
- Claims L A virtual money system comprising of: a real time transaction whereby a mobile phone communicates via the use of SMS technology, with a level 1 PCI compliant server which would in turn communicate with a variety of payment solutions and credit card acquirers and register a withdrawal of money, and the server would then facilitate the transfer of monies from the user to a retailer in order to purchase goods.
- 2. A virtual payment system comprising of: a real time transaction whereby the retafler mobile device communicates a product receipt via SMS and/or H1TPS, through a level 1 PCI compliant server, which is sent to a user mobile phone, in reply the user mobile phone communicates the receipt number and a user unique account code to the server, the server,after receipt of confirmation from the user mobile phone, communicates with a payment solution module and registers a withdrawal of funds, the server would then facilitate the direct transfer of funds from the user to the retailer to complete the transaction characterised in that the system can be applied by any physical or online business.
- 3. A virtual money system which facilitates a safer way to go shopping as there will be no risk of losing cash/cards or even have them stolen, since you will no longer have to carry them with you.
- 4. A virtual money system which according to claim 1 will allow people to virtually pay' for whatever goods/products they wish to buy.
- 5. A virtual money system which according to claim 1 allows customers to automatically send the amount payable to the merchant instantly and securely without the need to physically hand over cash, or the need to enter secure information.
- 6. A virtual money system as claimed above which tracks the user's purchase usage via their mobile phone, providing a full transactional history.
- 7. A virtual money system as claimed above which allows retailer to perform directed advertising by uniquely target specific customers based on region, average amount spent by customer, promotion code used and product purchased via the user of SMS and MMS technology.
- 8. A virtual money system as claimed above which allows merchants to create unique SMS codes to be used as promotion codes, reservation codes, discount codes or information requesting codes.
- 9. A virtual money system which will NEVER reveal the customer's mobile number to any merchant.
- 10. A virtual money system which will keep a customer's mobile number secure at all times.
- 11. A virtual money system which can assist in finding a stolen mobile phone and prevent fraudsters from using a fraudulent account.
- 12. A virtual money system which does not require the merchant to change their existing system or to hove any software integration knowledge for their customers to benefit from it.
- 13. A virtual money system which would ensure secure transactions and no charge backs for the merchants using if.
- 14. A virtual money system which would be 100% level 1 PCI compliant.
- 15. A virtual money system as claimed above which will increase the range of countries and currencies a merchant can accept orders/transactions from via the use of dynamic currency conversion.
- 16. A virtual money system as claimed above which will work with any mobile phone.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0822386A GB2466038A (en) | 2008-12-09 | 2008-12-09 | Authorisation of cashless payment using SMS |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0822386A GB2466038A (en) | 2008-12-09 | 2008-12-09 | Authorisation of cashless payment using SMS |
Publications (2)
Publication Number | Publication Date |
---|---|
GB0822386D0 GB0822386D0 (en) | 2009-01-14 |
GB2466038A true GB2466038A (en) | 2010-06-16 |
Family
ID=40289686
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
GB0822386A Withdrawn GB2466038A (en) | 2008-12-09 | 2008-12-09 | Authorisation of cashless payment using SMS |
Country Status (1)
Country | Link |
---|---|
GB (1) | GB2466038A (en) |
Cited By (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2510430A (en) * | 2013-02-05 | 2014-08-06 | Barclays Bank Plc | System and method for mobile wallet data access |
US20150302391A1 (en) * | 2012-11-16 | 2015-10-22 | Mobile Payment Solutions Holding Nordic Ab | Method for making a payment using a portable communication device |
US9210573B2 (en) | 2011-12-27 | 2015-12-08 | Infosys Limited | Method and apparatus for registering a computing device with a service provider |
DK201670628A1 (en) * | 2016-05-19 | 2017-11-27 | Apple Inc | Remote authorization to proceed with an action |
US9842330B1 (en) | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US10142835B2 (en) | 2011-09-29 | 2018-11-27 | Apple Inc. | Authentication with secondary approver |
US10178234B2 (en) | 2014-05-30 | 2019-01-08 | Apple, Inc. | User interface for phone call routing among devices |
US10395128B2 (en) | 2017-09-09 | 2019-08-27 | Apple Inc. | Implementation of biometric authentication |
US10438205B2 (en) | 2014-05-29 | 2019-10-08 | Apple Inc. | User interface for payments |
US10484384B2 (en) | 2011-09-29 | 2019-11-19 | Apple Inc. | Indirect authentication |
US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
US10521579B2 (en) | 2017-09-09 | 2019-12-31 | Apple Inc. | Implementation of biometric authentication |
US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
US10956550B2 (en) | 2007-09-24 | 2021-03-23 | Apple Inc. | Embedded authentication systems in an electronic device |
US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
US11037150B2 (en) | 2016-06-12 | 2021-06-15 | Apple Inc. | User interfaces for transactions |
US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
US11126704B2 (en) | 2014-08-15 | 2021-09-21 | Apple Inc. | Authenticated device used to unlock another device |
US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
US11283916B2 (en) | 2017-05-16 | 2022-03-22 | Apple Inc. | Methods and interfaces for configuring a device in accordance with an audio tone signal |
US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
US11481769B2 (en) | 2016-06-11 | 2022-10-25 | Apple Inc. | User interface for transactions |
US11539831B2 (en) | 2013-03-15 | 2022-12-27 | Apple Inc. | Providing remote interactions with host device using a wireless device |
US11620103B2 (en) | 2019-05-31 | 2023-04-04 | Apple Inc. | User interfaces for audio media control |
US11676373B2 (en) | 2008-01-03 | 2023-06-13 | Apple Inc. | Personal computing device control using face detection and recognition |
US11683408B2 (en) | 2017-05-16 | 2023-06-20 | Apple Inc. | Methods and interfaces for home media control |
US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
US11907013B2 (en) | 2014-05-30 | 2024-02-20 | Apple Inc. | Continuity of applications across devices |
US12002042B2 (en) | 2016-06-11 | 2024-06-04 | Apple, Inc | User interface for transactions |
US12079458B2 (en) | 2016-09-23 | 2024-09-03 | Apple Inc. | Image data for enhanced user interactions |
US12099586B2 (en) | 2021-01-25 | 2024-09-24 | Apple Inc. | Implementation of biometric authentication |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005029431A1 (en) * | 2003-09-22 | 2005-03-31 | Josko Maric | Sms/card system of paying goods and services via telecommunications devices |
US20070094150A1 (en) * | 2005-10-11 | 2007-04-26 | Philip Yuen | Transaction authorization service |
US20070107044A1 (en) * | 2005-10-11 | 2007-05-10 | Philip Yuen | System and method for authorization of transactions |
WO2008089383A2 (en) * | 2007-01-18 | 2008-07-24 | Mocapay, Inc. | Systems and method for secure wireless payment transactions |
US20080222048A1 (en) * | 2007-03-07 | 2008-09-11 | Higgins Kevin L | Distributed Payment System and Method |
-
2008
- 2008-12-09 GB GB0822386A patent/GB2466038A/en not_active Withdrawn
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005029431A1 (en) * | 2003-09-22 | 2005-03-31 | Josko Maric | Sms/card system of paying goods and services via telecommunications devices |
US20070094150A1 (en) * | 2005-10-11 | 2007-04-26 | Philip Yuen | Transaction authorization service |
US20070107044A1 (en) * | 2005-10-11 | 2007-05-10 | Philip Yuen | System and method for authorization of transactions |
WO2008089383A2 (en) * | 2007-01-18 | 2008-07-24 | Mocapay, Inc. | Systems and method for secure wireless payment transactions |
US20080222048A1 (en) * | 2007-03-07 | 2008-09-11 | Higgins Kevin L | Distributed Payment System and Method |
Cited By (85)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10956550B2 (en) | 2007-09-24 | 2021-03-23 | Apple Inc. | Embedded authentication systems in an electronic device |
US11468155B2 (en) | 2007-09-24 | 2022-10-11 | Apple Inc. | Embedded authentication systems in an electronic device |
US11676373B2 (en) | 2008-01-03 | 2023-06-13 | Apple Inc. | Personal computing device control using face detection and recognition |
US11755712B2 (en) | 2011-09-29 | 2023-09-12 | Apple Inc. | Authentication with secondary approver |
US11200309B2 (en) | 2011-09-29 | 2021-12-14 | Apple Inc. | Authentication with secondary approver |
US10484384B2 (en) | 2011-09-29 | 2019-11-19 | Apple Inc. | Indirect authentication |
US10142835B2 (en) | 2011-09-29 | 2018-11-27 | Apple Inc. | Authentication with secondary approver |
US10516997B2 (en) | 2011-09-29 | 2019-12-24 | Apple Inc. | Authentication with secondary approver |
US10419933B2 (en) | 2011-09-29 | 2019-09-17 | Apple Inc. | Authentication with secondary approver |
US9210573B2 (en) | 2011-12-27 | 2015-12-08 | Infosys Limited | Method and apparatus for registering a computing device with a service provider |
US20150302391A1 (en) * | 2012-11-16 | 2015-10-22 | Mobile Payment Solutions Holding Nordic Ab | Method for making a payment using a portable communication device |
GB2510430A (en) * | 2013-02-05 | 2014-08-06 | Barclays Bank Plc | System and method for mobile wallet data access |
US11539831B2 (en) | 2013-03-15 | 2022-12-27 | Apple Inc. | Providing remote interactions with host device using a wireless device |
US11494046B2 (en) | 2013-09-09 | 2022-11-08 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
US10372963B2 (en) | 2013-09-09 | 2019-08-06 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US10803281B2 (en) | 2013-09-09 | 2020-10-13 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US10410035B2 (en) | 2013-09-09 | 2019-09-10 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US10055634B2 (en) | 2013-09-09 | 2018-08-21 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US11768575B2 (en) | 2013-09-09 | 2023-09-26 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
US11287942B2 (en) | 2013-09-09 | 2022-03-29 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces |
US10262182B2 (en) | 2013-09-09 | 2019-04-16 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
US10977651B2 (en) | 2014-05-29 | 2021-04-13 | Apple Inc. | User interface for payments |
US10748153B2 (en) | 2014-05-29 | 2020-08-18 | Apple Inc. | User interface for payments |
US10796309B2 (en) | 2014-05-29 | 2020-10-06 | Apple Inc. | User interface for payments |
US11836725B2 (en) | 2014-05-29 | 2023-12-05 | Apple Inc. | User interface for payments |
US10438205B2 (en) | 2014-05-29 | 2019-10-08 | Apple Inc. | User interface for payments |
US10902424B2 (en) | 2014-05-29 | 2021-01-26 | Apple Inc. | User interface for payments |
US10616416B2 (en) | 2014-05-30 | 2020-04-07 | Apple Inc. | User interface for phone call routing among devices |
US10178234B2 (en) | 2014-05-30 | 2019-01-08 | Apple, Inc. | User interface for phone call routing among devices |
US11907013B2 (en) | 2014-05-30 | 2024-02-20 | Apple Inc. | Continuity of applications across devices |
US11126704B2 (en) | 2014-08-15 | 2021-09-21 | Apple Inc. | Authenticated device used to unlock another device |
US11206309B2 (en) | 2016-05-19 | 2021-12-21 | Apple Inc. | User interface for remote authorization |
US10334054B2 (en) | 2016-05-19 | 2019-06-25 | Apple Inc. | User interface for a device requesting remote authorization |
DK179186B1 (en) * | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
US10749967B2 (en) | 2016-05-19 | 2020-08-18 | Apple Inc. | User interface for remote authorization |
US9847999B2 (en) | 2016-05-19 | 2017-12-19 | Apple Inc. | User interface for a device requesting remote authorization |
DK201670628A1 (en) * | 2016-05-19 | 2017-11-27 | Apple Inc | Remote authorization to proceed with an action |
US12002042B2 (en) | 2016-06-11 | 2024-06-04 | Apple, Inc | User interface for transactions |
US11481769B2 (en) | 2016-06-11 | 2022-10-25 | Apple Inc. | User interface for transactions |
US11900372B2 (en) | 2016-06-12 | 2024-02-13 | Apple Inc. | User interfaces for transactions |
US11037150B2 (en) | 2016-06-12 | 2021-06-15 | Apple Inc. | User interfaces for transactions |
US11074572B2 (en) | 2016-09-06 | 2021-07-27 | Apple Inc. | User interfaces for stored-value accounts |
US9842330B1 (en) | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
US12079458B2 (en) | 2016-09-23 | 2024-09-03 | Apple Inc. | Image data for enhanced user interactions |
US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
US11995171B2 (en) | 2016-10-25 | 2024-05-28 | Apple Inc. | User interface for managing access to credentials for use in an operation |
US11574041B2 (en) | 2016-10-25 | 2023-02-07 | Apple Inc. | User interface for managing access to credentials for use in an operation |
US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
US12107985B2 (en) | 2017-05-16 | 2024-10-01 | Apple Inc. | Methods and interfaces for home media control |
US11683408B2 (en) | 2017-05-16 | 2023-06-20 | Apple Inc. | Methods and interfaces for home media control |
US11412081B2 (en) | 2017-05-16 | 2022-08-09 | Apple Inc. | Methods and interfaces for configuring an electronic device to initiate playback of media |
US11201961B2 (en) | 2017-05-16 | 2021-12-14 | Apple Inc. | Methods and interfaces for adjusting the volume of media |
US11283916B2 (en) | 2017-05-16 | 2022-03-22 | Apple Inc. | Methods and interfaces for configuring a device in accordance with an audio tone signal |
US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
US11095766B2 (en) | 2017-05-16 | 2021-08-17 | Apple Inc. | Methods and interfaces for adjusting an audible signal based on a spatial position of a voice command source |
US11750734B2 (en) | 2017-05-16 | 2023-09-05 | Apple Inc. | Methods for initiating output of at least a component of a signal representative of media currently being played back by another device |
US10395128B2 (en) | 2017-09-09 | 2019-08-27 | Apple Inc. | Implementation of biometric authentication |
US10410076B2 (en) | 2017-09-09 | 2019-09-10 | Apple Inc. | Implementation of biometric authentication |
US10521579B2 (en) | 2017-09-09 | 2019-12-31 | Apple Inc. | Implementation of biometric authentication |
US11393258B2 (en) | 2017-09-09 | 2022-07-19 | Apple Inc. | Implementation of biometric authentication |
US11386189B2 (en) | 2017-09-09 | 2022-07-12 | Apple Inc. | Implementation of biometric authentication |
US10783227B2 (en) | 2017-09-09 | 2020-09-22 | Apple Inc. | Implementation of biometric authentication |
US10872256B2 (en) | 2017-09-09 | 2020-12-22 | Apple Inc. | Implementation of biometric authentication |
US11765163B2 (en) | 2017-09-09 | 2023-09-19 | Apple Inc. | Implementation of biometric authentication |
US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
US11928200B2 (en) | 2018-06-03 | 2024-03-12 | Apple Inc. | Implementation of biometric authentication |
US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
US12105874B2 (en) | 2018-09-28 | 2024-10-01 | Apple Inc. | Device control using gaze information |
US12124770B2 (en) | 2018-09-28 | 2024-10-22 | Apple Inc. | Audio assisted enrollment |
US11809784B2 (en) | 2018-09-28 | 2023-11-07 | Apple Inc. | Audio assisted enrollment |
US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
US11619991B2 (en) | 2018-09-28 | 2023-04-04 | Apple Inc. | Device control using gaze information |
US11755273B2 (en) | 2019-05-31 | 2023-09-12 | Apple Inc. | User interfaces for audio media control |
US11853646B2 (en) | 2019-05-31 | 2023-12-26 | Apple Inc. | User interfaces for audio media control |
US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
US11620103B2 (en) | 2019-05-31 | 2023-04-04 | Apple Inc. | User interfaces for audio media control |
US11010121B2 (en) | 2019-05-31 | 2021-05-18 | Apple Inc. | User interfaces for audio media control |
US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
US11782598B2 (en) | 2020-09-25 | 2023-10-10 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
US12112037B2 (en) | 2020-09-25 | 2024-10-08 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
US12099586B2 (en) | 2021-01-25 | 2024-09-24 | Apple Inc. | Implementation of biometric authentication |
US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
Also Published As
Publication number | Publication date |
---|---|
GB0822386D0 (en) | 2009-01-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
GB2466038A (en) | Authorisation of cashless payment using SMS | |
US9805362B2 (en) | Mobile devices for activating instant disposable payment cards | |
US9224154B2 (en) | System and method for administering a loyalty program and processing payments | |
US6805289B2 (en) | Prepaid card payment system and method for electronic commerce | |
US20090182674A1 (en) | Facilitating financial transactions with a network device | |
US9536256B2 (en) | Systems and methods for stored-value exchange within social networking environments | |
US11580464B2 (en) | Consumers management system | |
US9811837B2 (en) | System and method for setting a product watch on transaction data | |
US7229014B1 (en) | systems and methods for account number generation and provisioning | |
US20130085877A1 (en) | Intermediary-based transaction system | |
US20040083170A1 (en) | System and method of integrating loyalty/reward programs with payment identification systems | |
US20020046341A1 (en) | System, and method for prepaid anonymous and pseudonymous credit card type transactions | |
JP2006012175A (en) | System and method for coordinating payment identification system | |
US20140058834A1 (en) | Providing targeted offers on financial transaction receipts | |
MX2013002228A (en) | Authorization of cash delivery. | |
EP1616308A2 (en) | Payment apparatus and method | |
KR100342658B1 (en) | Method for notifying credit transaction information | |
WO2013120007A1 (en) | Using credit card/bank rails to access a user's account at a pos | |
US20120323710A1 (en) | Method and system for storing and using identifying account information on an electronic device | |
WO2014118617A1 (en) | Offline vcard | |
US20140039973A1 (en) | System and method for setting a hot product alert on transaction data | |
US20140214669A1 (en) | Methods for Reducing the Merchant Chargeback Notification Time | |
JP2003168063A (en) | Method and system for approving payment in card payment method | |
WO2014043536A1 (en) | Consumer processing of payments for merchants | |
KR102074443B1 (en) | Server and client of paying using main card information |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |