1 / 33

Creating an In-Aisle Purchasing System from Scratch

The future of retail is in removing the divide between the offline shopping state and the enhanced online buying experience. To create this type of enhanced retail experience, we can remove complexities in the process, such as simplifying checkout. In this session we’ll learn how to use internet-connected microelectronics to attach to a buyer’s mobile device to provide the functionality to buy products right from the aisle.

jcleblanc
Download Presentation

Creating an In-Aisle Purchasing System from Scratch

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Creating an In-Aisle Purchasing System from Scratch Jonathan LeBlanc Twitter: @jcleblanc

  2. • Apple / Android pay type integrations • Secure hardware prototype integrations with microelectronics • Non-register integrations

  3. • Generating, handling, and securing tokens • Building an unbound physical payment architecture • Creating secure payment transmission through potentially poorly secured hardware

  4. A Bit on Tokens

  5. Tokenization Luhn Algorithm

  6. Token Durability Types • Durable: Long lived (~ 48 months), allows customer tracking, merchant preferred. • Transaction: One time use, more secure, ideal for small businesses not tracking customers.

  7. For our use case Process Create a surrogate value for customer credit card data Attributes • 13 – 19 digits in length • Passes Luhn check validation

  8. The LuhnAlgorithm 4539248095434517 7154345908429354 Starting Value Reverse Digits Multiply even digits by 2 7+(2)+5+(8)+3+(8)+5+(18)+0+(16)+4+(4)+9+(6)+5+(8) Subtract 9 from numbers above 9 7+(2)+5+(8)+3+(8)+5+(9)+0+(7)+4+(4)+9+(6)+5+(8) 90 0 (remainder) Sum all digits Mod 10 verify

  9. Apple / Android pay tokenization system EMV payment tokenisation specification

  10. Network handles direct merchant requests. Vault stores surrogate to token lookup. Merchant register is changed to hardware transfer bridge

  11. Customer to Device Interaction

  12. Host-based Card Emulation Secure Element

  13. Arduino with NFC or BLE Shield

  14. Beacon BLE Hardware

  15. How do you protect privileged information during data transmission?

  16. Asynchronous Cryptography: Securing Data Through Transmission

  17. Device Fingerprinting

  18. Getting Paired Devices

  19. Example Payload for Risk Assurance Data { requsterid: ‘1234’, usertoken: ‘443478943234’, device: { ... }, payment: { price: ’20.22’, currency: ‘CAD’, quantity: ‘2’ } }

  20. The API Network

  21. API Endpoints Needed /device issue / delete a requester ID for a verified hardware device or terminal. issue / update / cancel a verified payment from a customer. /pay issue / update / delete a new encryption key set for a customer device (phone). /key

  22. When generating new user tokens, how can we reduce the possibility of token collision?

  23. Using Respected Modules Example Packages (Node) • node-uuid • hat Reducing Collision Risk • hat.rack() function • Additional params to node-uuid or hat to further randomize the generated token

  24. The Token Vault

  25. Token Vault Security Strong physical and logical security measures per industry standards (PCI DSS, OWASP, etc). • Secured internal network • Strong cryptography and security protocols • Restrict user access and roles to system • System is protected from vulnerabilities • ... • Transactions are restricted to domains that are registered to valid token requesters. •

  26. Credit Card Vaulting https://developer.paypal.com/docs/api/vault/ Credit Card Information 7e29c5c48f44755598dec3549155ad6 6f1af4671091353be4c4d7694d71dc8 66 Address Information Card Holder Name ...

  27. CAP Theorem Consistency: Data to and from different nodes in the distributed system should always be identical. • Availability: The vault is always available to service requests. • Partition Tolerance: The distributed system can continue to work even in the event of underlying data communications network failure, or hardware failure in a node. •

  28. If consistency is dropped, how do we ensure that the payment token retrieved is the correct and newest one?

  29. Multiple Record Storage Surrogate Token Payment Token Delete 5256771698017130 d66f1af4671091353be4c true 5355427967576526 d66f1af4671091353be4c false 5535770792529787 7e29c5c48f4475523ef56 false

  30. Wrapup Links Host Card Emulation (Android): https://developer.android.com/guide/topics/connectivity/nfc/hce.html • EMV Tokenisation specification: https://www.emvco.com/specifications.aspx?id=263 • Asynchronous cryptography example: https://github.com/iddatasecuritybook/chapter7/tree/master/asymmetric-crypto • Android Build info: http://developer.android.com/reference/android/os/Build.html •

  31. Thank you! Slides: slideshare.net/jcleblanc Jonathan LeBlanc Twitter: @jcleblanc

More Related