Γιατί το λογισμικό προγράμματος πιστότητας αποτυγχάνει σε υλικό POS που είναι κλειδωμένο;

Ένα πρόγραμμα επιβράβευσης πελατών αποτυγχάνει σε ένα τερματικό POS για έναν λόγο περισσότερο από οποιονδήποτε άλλο: το υλικό δεν κατασκευάστηκε ποτέ για να επιτρέπει την είσοδο εξωτερικού λογισμικού. Οι λιανοπωλητές αγοράζουν μια πλατφόρμα επιβράβευσης πελατών, υπογράφουν τη σύμβαση, προϋπολογίζουν την ανάπτυξη και στη συνέχεια ανακαλύπτουν ότι το λειτουργικό σύστημα, το SDK ή η πιστοποίηση πληρωμής του τερματικού εμποδίζουν εντελώς την ενσωμάτωση. Αυτό δεν είναι πρόβλημα λογισμικού. Είναι πρόβλημα αρχιτεκτονικής υλικού και εμφανίζεται σχεδόν κάθε φορά που ένας έμπορος προσπαθεί να συνδέσει ένα σύστημα POS με λειτουργικότητα προγράμματος επιβράβευσης πελατών σε ένα τερματικό που σχεδιάστηκε ως κλειστή συσκευή πληρωμών και όχι ως ανοιχτή υπολογιστική συσκευή.
Πριν από την αξιολόγηση οποιασδήποτε πλατφόρμας, είναι χρήσιμο να διευθετηθεί το βασικό ερώτημα για το τι μπορεί και τι δεν μπορεί να κάνει ένα τερματικό POS με δεδομένα ανταμοιβών — επειδή η απάντηση εξαρτάται εξ ολοκλήρου από το υλικό που βρίσκεται από κάτω, όχι από τη λίστα χαρακτηριστικών του λογισμικού πιστότητας πελατών.
Αυτό το άρθρο αναλύει τους συγκεκριμένους τεχνικούς λόγους για τους οποίους τα συστήματα POS με ενσωματωμένο σύστημα πιστότητας αποτυγχάνουν σε κλειδωμένο υλικό, τι σημαίνει στην πραγματικότητα η φράση "κλειδωμένο" σε επίπεδο λειτουργικού συστήματος και πιστοποίησης και πώς μοιάζει μια λίστα ελέγχου αξιολόγησης για εμπόρους που χρειάζονται ένα σύστημα POS πιστότητας πελατών που λειτουργεί πραγματικά στην παραγωγή.

1. Τι σημαίνει στην πραγματικότητα ο όρος «κλειδωμένο υλικό POS»

Το υλικό POS με κλειδωμένη λειτουργία είναι ένα τερματικό όπου ο κατασκευαστής περιορίζει ποιες εφαρμογές μπορούν να εκτελούνται, σε ποιους πόρους συστήματος μπορούν να έχουν πρόσβαση αυτές οι εφαρμογές ή και τα δύο. Πρόκειται για μια σκόπιμη επιλογή σχεδιασμού, όχι για ελάττωμα. Τα παραδοσιακά τερματικά με κάρτα — οι μονάδες πάγκου που κατασκευάζονται κυρίως για συναλλαγές EMV και PIN — είναι πιστοποιημένα σύμφωνα με τα πρότυπα PCI PTS POI που αντιμετωπίζουν ολόκληρη τη συσκευή ως ένα ενιαίο αξιόπιστο περιβάλλον πληρωμών. Η προσθήκη μιας εφαρμογής πιστότητας σε αυτό το περιβάλλον ιστορικά σήμαινε την προσθήκη μιας μη επαληθευμένης διαδρομής κώδικα δίπλα στα δεδομένα του κατόχου της κάρτας, κάτι που δεν επιτρέπουν οι μάρκες πληρωμών και οι αγοραστές.
Τρία χαρακτηριστικά υλικού ορίζουν ένα κλειδωμένο τερματικό:

• ● Ένα κλειστό ή λειτουργικό σύστημα με μεγάλους περιορισμούς, χωρίς κατάστημα εφαρμογών και χωρίς διαδρομή παράπλευρης φόρτωσης.
• ● Δεν υπάρχει δημοσιευμένο SDK ή υπάρχει SDK που περιορίζεται στη μορφοποίηση αποδείξεων και στις βασικές περιφερειακές κλήσεις.
• ● Ένα μοντέλο υλικολογισμικού μίας εφαρμογής, όπου η εφαρμογή πληρωμών είναι η μόνη εφαρμογή που εκτελείται στη συσκευή.

Κανένα από αυτά τα χαρακτηριστικά δεν είναι εγγενώς λανθασμένο. Τα ειδικά τερματικά με κάρτα από παλαιούς προμηθευτές έχουν σχεδιαστεί με αυτόν τον τρόπο, ειδικά για να ελαχιστοποιήσουν το εύρος του ελέγχου PCI DSS. Το πρόβλημα εμφανίζεται μόνο όταν ένας έμπορος αναμένει ότι το ίδιο τερματικό θα εκτελεί επίσης μια θέση πώλησης με μονάδα προγράμματος επιβράβευσης, συγχρονισμό CRM ή εφαρμογή μάρκετινγκ — δυνατότητες για τις οποίες το υλικό δεν είχε ποτέ πιστοποιηθεί ή σχεδιαστεί για να υποστηρίζει.

2. Γιατί το Λογισμικό Πιστότητας παρουσιάζει σφάλματα σε κλειστές αρχιτεκτονικές POS

Οι ενσωματώσεις πιστότητας αποτυγχάνουν σε κλειστές αρχιτεκτονικές για τρεις επαναλαμβανόμενους τεχνικούς λόγους: οι κανόνες sandboxing περιορίζουν την πρόσβαση στα δεδομένα, τα ιδιόκτητα SDK εμποδίζουν την εγκατάσταση και οι κύκλοι ενημέρωσης υλικολογισμικού καθυστερούν την κυκλοφορία λειτουργιών.

2.1 Οι κανόνες sandboxing του PCI PTS περιορίζουν την πρόσβαση σε δεδομένα τρίτων

Η έκδοση 7.0 του PCI PTS POI, η οποία δημοσιεύτηκε από το Συμβούλιο Προτύπων Ασφαλείας PCI, επιτρέπει πλέον σε εφαρμογές τρίτων, όπως εφαρμογές καταστήματος εφαρμογών, να εκτελούνται σε πιστοποιημένες συσκευές POI. Ωστόσο, το πρότυπο απαιτεί αυτές οι εφαρμογές να είναι... ασφαλώς απομονωμένο από ευαίσθητες λειτουργίες πληρωμών και επικυρωμένο με κρυπτογραφικά στοιχεία ελέγχουΜια νεότερη απαίτηση στην ίδια έκδοση εμποδίζει τις εφαρμογές τρίτων να διαβάζουν δεδομένα PAN ή PIN σε απλό κείμενο, ακόμη και όταν η εφαρμογή βρίσκεται σε εγκεκριμένη λίστα επιτρεπόμενων. Για μια μηχανή επιβράβευσης πιστών πελατών, αυτό έχει άμεση σημασία: οποιοδήποτε μοτίβο ενσωμάτωσης που υποθέτει ότι η εφαρμογή επιβράβευσης πιστών πελατών μπορεί να διαβάσει το σύνολο της συναλλαγής, το διακριτικό κάρτας ή το αναγνωριστικό πελάτη απευθείας από τη διαδικασία πληρωμής δεν συμμορφώνεται με τις απαιτήσεις σε μια συσκευή πιστοποιημένη με v7.0. Η εφαρμογή επιβράβευσης πιστών πελατών πρέπει να λαμβάνει αυτά τα δεδομένα μέσω ενός εγκεκριμένου, απομονωμένου καναλιού — και σε πολλά κλειδωμένα τερματικά, δεν υπάρχει τέτοιο κανάλι.

2.2 Τα ιδιόκτητα SDK εμποδίζουν την εγκατάσταση εγγενών εφαρμογών πιστότητας

Μια πλατφόρμα πιστότητας πρέπει να εγγράφει πελάτες, να αναζητά υπόλοιπα πόντων, να εφαρμόζει εξαργυρώσεις και να εκτυπώνει ή να εμφανίζει ανταμοιβές στο σημείο πώλησης. Κάθε μία από αυτές τις ενέργειες χρειάζεται ένα άγκιστρο SDK. Τα τερματικά με κλειστό λειτουργικό σύστημα, ιδιοκτησίας προμηθευτή, συνήθως δεν εκθέτουν κανένα από αυτά τα άγκιστρα σε εξωτερικούς προγραμματιστές — ο προμηθευτής πιστότητας μένει να ενσωματώνεται μέσω ενός webhook πύλης πληρωμής αφού η συναλλαγή έχει ήδη κλείσει, κάτι που είναι πολύ αργά για να εφαρμοστεί μια έκπτωση σε πραγματικό χρόνο ή να ενεργοποιηθεί μια ανταμοιβή εντός περιόδου σύνδεσης. Αυτό είναι το πιο συνηθισμένο μοτίβο αποτυχίας που αναφέρεται από εμπόρους που μεταβαίνουν από παλαιά τερματικά πάγκου σε αναπτύξεις προγραμμάτων πιστότητας POS: η ενσωμάτωση τεχνικά «λειτουργεί» ως συγχρονισμός μετά τη συναλλαγή, αλλά δεν μπορεί να κάνει τίποτα στο σημείο της ίδιας της αλληλεπίδρασης.

2.3 Οι κύκλοι ενημέρωσης υλικολογισμικού τερματίζουν την κυκλοφορία των λειτουργιών πιστότητας

Ακόμα και όταν ένα κλειδωμένο τερματικό εκθέτει ένα περιορισμένο SDK, το υλικολογισμικό σε συσκευές πληρωμών μίας χρήσης ενημερώνεται συνήθως με αργό, χρονοδιάγραμμα που βασίζεται στην πιστοποίηση, καθώς κάθε αλλαγή υλικολογισμικού μπορεί να ενεργοποιήσει την επαναπιστοποίηση PCI. Ένας προμηθευτής πιστότητας που θέλει να στείλει έναν νέο κανόνα εξαργύρωσης, μια νέα ροή εγγραφής ή ένα νέο επίπεδο ανταμοιβών πρέπει να περιμένει τον κύκλο κυκλοφορίας του προμηθευτή υλικού — όχι τον δικό του. Σε ένα ανοιχτό τερματικό POS Android, η εφαρμογή πιστότητας ενημερώνεται ανεξάρτητα μέσω του δικού της πακέτου εφαρμογής, χωρίς καμία εξάρτηση από το υλικολογισμικό του τερματικού.

3. Το πραγματικό κόστος μιας αποτυχημένης ενσωμάτωσης πιστότητας

Το άμεσο κόστος μιας αποτυχημένης ενσωμάτωσης είναι η στασιμότητα ή η αντιστροφή της εφαρμογής, αλλά το μεγαλύτερο κόστος είναι στρατηγικό: οι λιανοπωλητές συνεχίζουν να αγοράζουν λογισμικό επιβράβευσης πελατών με αυξανόμενο ρυθμό, ενώ η συμβατότητα υλικού παραμένει δευτερεύουσας σημασίας. Η παγκόσμια αγορά διαχείρισης επιβράβευσης πελατών έφτασε τα 17.38 δισεκατομμύρια δολάρια το 2026 και προβλέπεται να αυξηθεί με σύνθετο ετήσιο ρυθμό άνω του 14% έως το 2034. Κάθε δολάριο που δαπανάται σε μια πλατφόρμα επιβράβευσης πελατών που δεν μπορεί στην πραγματικότητα να λειτουργήσει στο υλικό του ταμείου είναι ένα δολάριο που δαπανάται δύο φορές - μία φορά στο λογισμικό, άλλη μια φορά σε μια ανανέωση υλικού που θα έπρεπε να είχε συμβεί πρώτα.
Υπάρχει επίσης ένα κόστος συμμόρφωσης. Τα προγράμματα πιστότητας συλλέγουν και επεξεργάζονται προσωπικά δεδομένα πελατών — ονόματα, αριθμούς τηλεφώνου, ιστορικό αγορών, μερικές φορές βιομετρικά δεδομένα εγγραφής για προγράμματα με δυνατότητα tap-to-identify. Σύμφωνα με τον κανονισμό της ΕΕ 2016/679 (ΓΚΠΔ), ότι η επεξεργασία απαιτεί τεκμηριωμένη νόμιμη βάση και μια ροή συναίνεσης κατά την εγγραφή. Μια ενσωμάτωση πιστότητας που επιβάλλεται μέσω μιας ανεπίσημης λύσης — ένα τερματικό με jailbreak, ένα μη υποστηριζόμενο APK με παράπλευρη φόρτωση, μια γέφυρα απόξεσης οθόνης — καθιστά πολύ πιο δύσκολο να παραχθεί αυτή η τεκμηρίωση συμμόρφωσης κατά τη διάρκεια ενός ελέγχου, επειδή η ίδια η διαδρομή δεδομένων δεν σχεδιάστηκε ποτέ για να αναθεωρηθεί.

4. Πώς μοιάζει μια ανοιχτή αρχιτεκτονική POS έτοιμη για πιστότητα

Μια αρχιτεκτονική που υποστηρίζει την πιστότητα (loyalty) μοιράζεται αξιόπιστα τρία χαρακτηριστικά: ένα ανοιχτό SDK, μια διανομή λογισμικού σε επίπεδο app-store και χαρακτηριστικά ταυτότητας υλικού που ξεπερνούν μια απλή σάρωση κάρτας.

4.1 Ανοιχτό SDK και πρόσβαση API

Τα τερματικά POS που βασίζονται σε Android με δημοσιευμένο SDK επιτρέπουν σε έναν προμηθευτή πιστότητας να δημιουργεί απευθείας σε τεκμηριωμένα API για τον εκτυπωτή, τον σαρωτή, την οθόνη που βλέπει τον πελάτη και τον πυρήνα πληρωμών — χωρίς να περιμένει τον κατασκευαστή υλικού για κάθε νέα λειτουργία. Αυτό είναι το ίδιο μοντέλο ανοιχτής πλατφόρμας που εισήγαγε το Terminal API της Square για το δικό του υλικό και πλέον αποτελεί συνήθη πρακτική στους περισσότερους κατασκευαστές POS Android που πωλούν σε περιβάλλοντα λιανικής πώλησης πολλαπλών προμηθευτών αντί για κλειστά περίπτερα μίας εφαρμογής. Οι έμποροι προμηθεύονται υλικό απευθείας από τη βάση εφοδιασμού — συμπεριλαμβανομένων των Τοπίο B2B των Κινέζων κατασκευαστών τερματικών POS — θα πρέπει να αντιμετωπίζει την ανοιχτότητα του SDK ως φίλτρο προμηθειών και όχι ως μια δευτερεύουσα σκέψη που συζητείται μόνο μετά την υπογραφή της σύμβασης.

4.2 Πιστοποίηση GMS και Συμβατότητα με το App Store

Η πιστοποίηση Google Mobile Services (GMS) επιτρέπει σε ένα τερματικό να εκτελεί τυπικά πακέτα εφαρμογών Android μέσω του Play Store ή ενός ισοδύναμου διαχειριζόμενου καταστήματος εφαρμογών, αντί να περιορίζει τη συσκευή σε λογισμικό που περιλαμβάνει υλικολογισμικό. Ένα τερματικό με πιστοποίηση GMS μπορεί να εγκαταστήσει μια εφαρμογή επιβράβευσης πελατών με τον ίδιο τρόπο που ένα τηλέφωνο εγκαθιστά οποιαδήποτε άλλη εφαρμογή: ανεξάρτητα, σύμφωνα με το πρόγραμμα κυκλοφορίας του ίδιου του προμηθευτή, χωρίς κύκλο επαναπιστοποίησης σε επίπεδο υλικολογισμικού.

4.3 Εγγραφή σε πρόγραμμα βιομετρικής πιστότητας

Ένα μικρότερο αλλά αυξανόμενο σύνολο τερματικών επεκτείνει την αναγνώριση πιστότητας πέρα ​​από κάρτες και αριθμούς τηλεφώνου σε βιομετρική εγγραφή. Η αναγνώριση φλεβών παλάμης είναι ένα παράδειγμα που ήδη βρίσκεται σε εμπορική εφαρμογή — ZCS είναι μεταξύ των κατασκευαστών POS Android που διαθέτουν αυτήν τη στιγμή τερματικά με δυνατότητα φλεβών παλάμης με ανοιχτό SDK, επιτρέποντας σε μια πλατφόρμα πιστότητας να εγγράψει το μοτίβο φλεβών παλάμης ενός πελάτη ως εναλλακτικό αναγνωριστικό κατά την ολοκλήρωση της αγοράς αντί να απαιτεί αναζήτηση κάρτας, εφαρμογής ή αριθμού τηλεφώνου. Αυτό το είδος δυνατότητας ταυτότητας σε επίπεδο υλικού μπορεί να χρησιμοποιηθεί από μια πλατφόρμα πιστότητας μόνο όταν το SDK του τερματικού το εκθέτει ως τεκμηριωμένο API — κάτι που είναι ακριβώς η απαίτηση ανοιχτής αρχιτεκτονικής που περιγράφεται παραπάνω, όχι μια δυνατότητα μοναδική για οποιαδήποτε μάρκα.

5. Λίστα ελέγχου αξιολόγησης: Είναι το τερματικό POS σας έτοιμο για πιστότητα πελατών;

Πριν υπογράψετε μια σύμβαση λογισμικού επιβράβευσης, επιβεβαιώστε τα εξής στην πλευρά του τερματικού:

• ● Το τερματικό συνοδεύεται από ένα δημοσιευμένο, τεκμηριωμένο SDK — όχι απλώς ένα webhook πύλης πληρωμών.
• ● Το τερματικό είναι πιστοποιημένο από GMS και υποστηρίζει ανεξάρτητη εγκατάσταση και ενημερώσεις εφαρμογών.
• ● Ο κατασκευαστής μπορεί να επιβεβαιώσει τη συμμόρφωση με το PCI PTS POI για οποιαδήποτε sandboxing εφαρμογών τρίτου μέρους, που να αντιστοιχεί στις απαιτήσεις απομόνωσης στην τρέχουσα έκδοση PTS POI.
• ● Ο προμηθευτής πιστότητας μπορεί να ονομάσει έναν ζωντανό έμπορο αναφοράς που χρησιμοποιεί το ακριβές μοντέλο τερματικού, όχι μόνο την επωνυμία του τερματικού.
• ● Ο ρυθμός κυκλοφορίας υλικολογισμικού του προμηθευτή υλικού καταγράφεται και δεν εμποδίζει τις ανεξάρτητες ενημερώσεις σε επίπεδο εφαρμογής από τον προμηθευτή πιστότητας.

Τα κριτήρια επιλογής τερματικού — ανοιχτό λειτουργικό σύστημα, πεδίο εφαρμογής πιστοποίησης, βάθος SDK — καλύπτονται με περισσότερες λεπτομέρειες στο το πλήρες πλαίσιό μας για την επιλογή μιας πλατφόρμας Android POS, η οποία ακολουθεί την ίδια λογική αξιολόγησης πέρα ​​από τις περιπτώσεις χρήσης πιστότητας και μόνο.

6. Συχνές Ερωτήσεις

Ε1: Μπορεί οποιοδήποτε τερματικό POS να εκτελέσει πρόγραμμα επιβράβευσης πελατών;

Όχι. Ένα τερματικό χρειάζεται ένα ανοιχτό SDK, διανομή λογισμικού σε επίπεδο καταστήματος εφαρμογών και sandboxing συμβατό με PCI PTS για εφαρμογές τρίτων. Τα κλειστά τερματικά μίας εφαρμογής περιορίζουν ή αποκλείουν εντελώς το λογισμικό επιβράβευσης πιστών πελατών, ανεξάρτητα από το τι υποστηρίζει η πλατφόρμα του προμηθευτή επιβράβευσης πιστών πελατών σε χαρτί.
Ε2: Τι καθιστά ένα τερματικό POS «κλειδωμένο»;

Ένα κλειδωμένο τερματικό περιορίζει τις εφαρμογές που μπορούν να εγκατασταθούν, δεν εκθέτει κανένα δημόσιο SDK και εκτελεί υλικολογισμικό που έχει δημιουργηθεί γύρω από μια ενιαία εφαρμογή πληρωμής. Αυτά τα χαρακτηριστικά μειώνουν το εύρος του ελέγχου PCI, αλλά επίσης αποκλείουν εφαρμογές επιβράβευσης πελατών, συγχρονισμούς CRM και άλλες ενσωματώσεις τρίτων εξ ορισμού.
Ε3: Η συμμόρφωση με το PCI εμποδίζει τις εφαρμογές πιστότητας να εκτελούνται σε υλικό POS;

Όχι από προεπιλογή. Το PCI PTS POI v7.0 επιτρέπει εφαρμογές τρίτων, συμπεριλαμβανομένων των εφαρμογών επιβράβευσης πιστών πελατών, υπό την προϋπόθεση ότι βρίσκονται σε sandbox μακριά από δεδομένα κάρτας πληρωμής και PIN με απλό κείμενο. Η συμμόρφωση απαιτεί απομόνωση, όχι αποκλεισμό, και η αρχιτεκτονική του τερματικού καθορίζει εάν αυτή η απομόνωση είναι τεχνικά εφικτή.
Ε4: Ποια είναι η διαφορά μεταξύ ενός συγχρονισμού αφοσίωσης μετά τη συναλλαγή και μιας ενσωμάτωσης σε πραγματικό χρόνο;

Ένας συγχρονισμός μετά τη συναλλαγή εφαρμόζει ανταμοιβές μετά το κλείσιμο της πώλησης, μέσω ενός webhook πύλης πληρωμών. Μια ενσωμάτωση σε πραγματικό χρόνο εφαρμόζει ανταμοιβές κατά την ολοκλήρωση της αγοράς, μέσω ενός hook SDK. Τα κλειδωμένα τερματικά συνήθως υποστηρίζουν μόνο το πρώτο, γεγονός που αποτρέπει τις εκπτώσεις και τις εξαργυρώσεις κατά τη διάρκεια της συνεδρίας.
Ε5: Μπορεί η βιομετρική ταυτοποίηση, όπως η φλέβα της παλάμης, να χρησιμοποιηθεί για την εγγραφή σε πρόγραμμα πιστότητας πελατών;

Ναι, σε τερματικά όπου ο κατασκευαστής εκθέτει βιομετρική καταγραφή μέσω ενός τεκμηριωμένου SDK. Τα βιομετρικά αναγνωριστικά της παλάμης και παρόμοια βιομετρικά αναγνωριστικά επιτρέπουν σε μια πλατφόρμα πιστότητας πελατών να αναγνωρίζει έναν πελάτη που επιστρέφει χωρίς αναζήτηση κάρτας, αριθμού τηλεφώνου ή εφαρμογής, υπό την προϋπόθεση ότι η αρχιτεκτονική υλικού υποστηρίζει την πρόσβαση τρίτων σε αυτά τα δεδομένα.