Confirmed users
483
edits
WebAPI/WebPaymentProvider: Difference between revisions
m
→Silent SMS
m (→Silent SMS) |
m (→Silent SMS) |
||
| Line 64: | Line 64: | ||
A example flow for an '''SMS MO + SMS MT''' scenario with a fake 123 charge free short code could be something like: | A example flow for an '''SMS MO + SMS MT''' scenario with a fake 123 charge free short code could be something like: | ||
* As the payment provider will be "talking" with the short code application for 123, the first step should be start observing the messages coming from that number. This is done via | * As the payment provider will be "talking" with the short code application for 123, the first step should be start observing the messages coming from that number. This is done via <code>mozPaymentProvider.observeSilentSms('123', onmessage);</code>, where <code>onmessage</code> is the callback that will handle the reception of an SMS coming from 123. | ||
* Once it is ready to handle messages from 123, the payment provider requests to send an SMS via | * Once it is ready to handle messages from 123, the payment provider requests to send an SMS via <code>var req = mozPaymentProvider.sendSilentSms('123', uuid);</code>. Where <code>uuid</code> is a variable containing the body of the SMS. It is recommendable to send a generated unique ID (uuid) as the message body, that will need to be sent back by the short code application, so the payment provider can match each send with its corresponding reply. The payment provider will need to keep track of these uuids and remove them as soon as a matching reply is received or after a timeout or send failure. The <code>req</code> variable returned by <code>sendSilentSms</code> is an instance of [https://developer.mozilla.org/en-US/docs/DOM/DOMRequest DOMRequest] and allows the payment provider to check if the SMS is successfully sent or not. | ||
* The message sent in the previous step is received by the short code application (on the carrier's side), which identifies the user as the sender of the SMS. The short code application sends back a message containing the uuid to the number of the sender of the previous message. | * The message sent in the previous step is received by the short code application (on the carrier's side), which identifies the user as the sender of the SMS. The short code application sends back a message containing the uuid to the number of the sender of the previous message. | ||
* The message sent by the short code application is intercepted by the payment provider and handled within the callback given to | * The message sent by the short code application is intercepted by the payment provider and handled within the callback given to <code>mozPaymentProvider.observeSilentSms</code> in the first step. If the uuid is correct, the payment provider knows that the user is properly authenticated by the carrier side and so it can continue with the payment process. | ||
* At this point, the payment provider should do its clean up for the uuid identifying the authentication flow. It can also call | * At this point, the payment provider should do its clean up for the uuid identifying the authentication flow. It can also call <code>mozPaymentProvider.removeSilentSmsObserver</code>, but as mentioned above, it is not mandatory. | ||
An '''SMS MO''' only flow is quite simpler and only requires a call to | An '''SMS MO''' only flow is quite simpler and only requires a call to <code>mozPaymentProvider.sendSilentSms</code>. | ||
== Payment Confirmation == | == Payment Confirmation == | ||