Creating an In-Aisle Purchasing System from Scratch
•Als PPTX, PDF herunterladen•
0 gefällt mir•499 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (7)
Ähnlich wie Creating an In-Aisle Purchasing System from Scratch
Ähnlich wie Creating an In-Aisle Purchasing System from Scratch (20)
Mehr von Jonathan LeBlanc
Mehr von Jonathan LeBlanc (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Creating an In-Aisle Purchasing System from Scratch
- 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
- 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. Process Create a surrogate value for customer credit card data Attributes • 13 – 19 digits in length • Passes Luhn check validation For our use case
- 8. Starting Value 4539248095434517 Reverse Digits 7154345908429354 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) Sum all digits 90 Mod 10 verify 0 (remainder) The Luhn Algorithm
- 9. Apple / Android pay tokenization system EMV payment tokenisation specification
- 11. Merchant register is changed to hardware transfer bridge Network handles direct merchant requests. Vault stores surrogate to token lookup.
- 12. Customer to Device Interaction
- 14. Arduino with NFC or BLE Shield
- 16. How do you protect privileged information during data transmission?
- 17. Asynchronous Cryptography: Securing Data Through Transmission
- 21. { requsterid: ‘1234’, usertoken: ‘443478943234’, device: { ... }, payment: { price: ’20.22’, currency: ‘CAD’, quantity: ‘2’ } } Example Payload for Risk Assurance Data
- 22. The API Network
- 23. /device issue / delete a requester ID for a verified hardware device or terminal. /pay issue / update / cancel a verified payment from a customer. /key issue / update / delete a new encryption key set for a customer device (phone). API Endpoints Needed
- 24. When generating new user tokens, how can we reduce the possibility of token collision?
- 25. 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 Using Respected Modules
- 26. The Token Vault
- 27. 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.
- 28. Credit Card Vaulting Credit Card Information Address Information Card Holder Name ... 7e29c5c48f44755598dec3549155ad6 6f1af4671091353be4c4d7694d71dc8 66 https://developer.paypal.com/docs/api/vault/
- 29. 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.
- 30. If consistency is dropped, how do we ensure that the payment token retrieved is the correct and newest one?
- 31. Multiple Record Storage Surrogate Token Payment Token Delete 5256771698017130 d66f1af4671091353be4c true 5355427967576526 d66f1af4671091353be4c false 5535770792529787 7e29c5c48f4475523ef56 false
- 32. 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
- 33. Thank you! Slides: slideshare.net/jcleblanc Jonathan LeBlanc Twitter: @jcleblanc
Hinweis der Redaktion
- What does this type of system enable? Walk around payment checkout Direct hardware / beacon payments in aisle Direct table purchases
- What we’ll learn today
- What does the token look like – 13-19 digit numeric value that passes account and Luhn check validation Durable vs transaction based tokens Durable: merchant preferred as it allows CC ad data storage. Faster purchases (don’t have to request a new token each time). Transaction: more secure, don’t need to track customer details. Good for small businesses
- tokenization
- Luhn algorithm https://www.rosettacode.org/wiki/Luhn_test_of_credit_card_numbers http://www.freeformatter.com/credit-card-number-generator-validator.html
- What we’ll model our breakdown around EMV payment tokenisation specification Apple / Android pay tokenization system
- How the apple / android pay system works (diagram)
- How our modified system will work
- Device / User integration
- Secure element functionality on the phone vs HCE
- Device hardware – arduino with BLE / NFC shield
- Beacon hardware
- Protecting card data prior to storage
- Asynchronous Cryptography
- Creating risk assurance information for verification by the API network
- The API network
- The endpoints needed for the network /device – create new verified endpoint device (providing a requester ID) /pay – make an encrypted payment /issue – issue new key set for data encryption (new mobile device)
- How do we ensure minimal collision in generated tokens?
- Node-uuid and hat Hat.rack func
- Some storage rules / regulations
- https://www.voltage.com/pci/tokenization-of-credit-card-numbers-and-the-cap-theorem/ The theorem states that for distributed data storage systems a system designer has to choose between two of the three following menu items: Consistency. In the card vault example this would imply that no matter which distributed tokenization service was used for tokenization or de-tokenization they would all return the exact same token for a given PAN. It would not be permissible, for example, to return two different tokens for a given PAN. Availability. The card vault is always available to service a request to tokenize or de-tokenize. Partition tolerance. This is perhaps the least understood of the three choices. In summary, for a distributed storage system the system can continue to operate even in the event of underlying data communications network failure, or hardware failure in a node.
- How do we ensure the consistency of tokens
- Store multiple records of token to payment token mapping with the outdated records flagged for deletion