Σε πολλές B2B πωλήσεις η παραγγελία δεν εξοφλείται με μία κίνηση. Μπορεί να απαιτείται προκαταβολή για να δεσμευτεί το απόθεμα, δεύτερη πληρωμή πριν από την αποστολή και τελική εξόφληση μετά την παράδοση. Άλλοτε ο πελάτης πληρώνει ένα μέρος με κάρτα και το υπόλοιπο με τραπεζική κατάθεση.
Αν το e-shop γνωρίζει μόνο τις καταστάσεις paid και unpaid, η πραγματικότητα μεταφέρεται σε σημειώσεις, spreadsheets και τηλεφωνήματα. Η σωστή υποστήριξη μερικών πληρωμών χρειάζεται ξεχωριστό μοντέλο για την παραγγελία, τις απαιτήσεις πληρωμής και τις πραγματικές συναλλαγές.
Προκαταβολή, δόση και partial capture δεν είναι το ίδιο
Οι όροι συχνά χρησιμοποιούνται σαν να είναι ταυτόσημοι, αλλά περιγράφουν διαφορετικές ροές:
- Προκαταβολή: ποσό που οφείλεται κατά την επιβεβαίωση και αφαιρείται από το συνολικό υπόλοιπο.
- Δόση: συμφωνημένο ποσό με συγκεκριμένη ημερομηνία ή ορόσημο.
- Μερική πληρωμή: οποιαδήποτε συναλλαγή καλύπτει μέρος της οφειλής.
- Partial capture: είσπραξη μέρους ενός ποσού που είχε προηγουμένως δεσμευτεί στην κάρτα.
- Split tender: εξόφληση μιας αγοράς με περισσότερες από μία μεθόδους πληρωμής.
Η διάκριση επηρεάζει το checkout, το λογιστήριο και τις δυνατότητες του payment provider. Μια δέσμευση κάρτας έχει χρονικά και τεχνικά όρια. Μια τραπεζική κατάθεση χρειάζεται χειροκίνητη ή αυτοματοποιημένη συμφωνία. Μια προκαταβολή σε B2B παραγγελία μπορεί να συνδέεται με όρους net 30 για το υπόλοιπο.
Το σωστό μοντέλο δεδομένων
Η συνολική αξία της παραγγελίας δεν πρέπει να ξαναγράφεται κάθε φορά που πληρώνεται ένα μέρος. Χρειάζονται τουλάχιστον τρεις έννοιες:
- Order total: η αξία της παραγγελίας, μαζί με φόρους, μεταφορικά και εκπτώσεις.
- Payment schedule: τι αναμένεται να πληρωθεί, πότε και με ποιον κανόνα.
- Payment transactions: τι πραγματικά εισπράχθηκε, επιστράφηκε ή απέτυχε.
Το outstanding balance υπολογίζεται από τα έγκυρα οικονομικά γεγονότα και όχι από ένα πεδίο που αλλάζει χειροκίνητα. Κάθε transaction χρειάζεται ποσό, νόμισμα, μέθοδο, provider reference, κατάσταση και ημερομηνία. Η εφαρμογή πρέπει επίσης να ξεχωρίζει μια προγραμματισμένη δόση από μια απόπειρα πληρωμής.
Έτσι το σύστημα μπορεί να απαντήσει με ακρίβεια: πόσο έχει πληρωθεί, πόσο οφείλεται, ποιο ποσό είναι ληξιπρόθεσμο και ποια συναλλαγή πρέπει να επιστραφεί.
Η εμπειρία του πελάτη
Στο checkout ο πελάτης πρέπει να βλέπει πριν επιβεβαιώσει:
- συνολική αξία παραγγελίας,
- ποσό που πληρώνεται τώρα,
- υπόλοιπο μετά την προκαταβολή,
- ημερομηνία ή συνθήκη εξόφλησης,
- διαθέσιμες μεθόδους για κάθε στάδιο,
- τι συμβαίνει αν η παραγγελία αλλάξει ή ακυρωθεί.
Οι ίδιες πληροφορίες πρέπει να εμφανίζονται στη σελίδα επιβεβαίωσης, στο email και στο customer account. Η επίσημη τεκμηρίωση του Shopify για B2B payment terms, για παράδειγμα, προβλέπει εμφάνιση της προκαταβολής και της ημερομηνίας υπολοίπου στο checkout και στην προβολή παραγγελίας. Η αρχή είναι σωστή ανεξάρτητα από πλατφόρμα: ο πελάτης δεν πρέπει να ανακαλύπτει αργότερα ότι υπάρχει διαφορετικό ποσό ή deadline.
Καταστάσεις που δεν πρέπει να συμπιεστούν σε ένα status
Το payment status και το fulfillment status είναι ανεξάρτητα. Μια παραγγελία μπορεί να είναι partially paid αλλά έτοιμη για παραγωγή, ή fully paid αλλά σε αναμονή αποθέματος.
Χρήσιμες καταστάσεις πληρωμής είναι pending deposit, partially paid, paid, overdue, partially refunded και refunded. Παράλληλα, κάθε δόση μπορεί να είναι scheduled, due, processing, settled, failed ή cancelled.
Μην αλλάζετε την παραγγελία σε paid επειδή καταγράφηκε μια τραπεζική κατάθεση χωρίς επιβεβαίωση. Μην θεωρείτε αποτυχία ολόκληρης της παραγγελίας επειδή απέτυχε η δεύτερη απόπειρα μιας δόσης. Η λεπτομέρεια ανήκει στις συναλλαγές και η συνολική εικόνα προκύπτει από αυτές.
Αλλαγές, ακυρώσεις και επιστροφές
Οι δύσκολες περιπτώσεις εμφανίζονται όταν αλλάξει η αξία μετά την προκαταβολή. Αν προστεθούν προϊόντα, πρέπει να αποφασιστεί αν αλλάζει η επόμενη δόση ή δημιουργείται νέα απαίτηση. Αν αφαιρεθούν, το σύστημα πρέπει να υπολογίσει αν μειώνεται το υπόλοιπο ή αν οφείλεται επιστροφή.
Σε ακύρωση, η πολιτική μπορεί να προβλέπει πλήρη επιστροφή, παρακράτηση μέρους ή store credit. Η εφαρμογή δεν πρέπει να επινοεί τον κανόνα. Πρέπει να εφαρμόζει την εμπορική πολιτική, να εμφανίζει το αποτέλεσμα πριν από την ενέργεια και να καταγράφει ποιος το ενέκρινε.
Τα refunds πρέπει να συνδέονται με συγκεκριμένες εισπράξεις. Αν ο πελάτης πλήρωσε με κάρτα και κατάθεση, η ομάδα χρειάζεται να γνωρίζει ποια μέθοδος επιστρέφει ποιο ποσό. Η επιστροφή δεν διαγράφει την αρχική συναλλαγή· δημιουργεί νέο οικονομικό γεγονός.
Συμφωνία με ERP και λογιστήριο
Το e-shop μπορεί να εμφανίζει σωστό υπόλοιπο, αλλά η επιχείρηση θα συνεχίσει να έχει πρόβλημα αν το ERP βλέπει μόνο μία εξόφληση. Η διασύνδεση χρειάζεται κοινά identifiers για order, installment και transaction.
Για τραπεζικές καταθέσεις, χρήσιμο είναι ένα μοναδικό payment reference που εμφανίζεται στις οδηγίες και μεταφέρεται στη συμφωνία. Οι μη αντιστοιχισμένες πληρωμές μπαίνουν σε queue για έλεγχο αντί να συνδέονται αυτόματα με βάση μόνο το ποσό.
Η ανταλλαγή δεδομένων πρέπει να είναι idempotent. Αν ένα webhook ή sync job εκτελεστεί δύο φορές, δεν πρέπει να δημιουργήσει διπλή πληρωμή. Τα failed syncs χρειάζονται retry με ιστορικό, ενώ το admin πρέπει να δείχνει αν η οικονομική εικόνα είναι συγχρονισμένη ή εκκρεμεί.
Αυτοματισμοί υπενθύμισης
Οι υπενθυμίσεις πρέπει να βασίζονται στο πραγματικό υπόλοιπο και στη σωστή ημερομηνία. Μια ασφαλής ροή ελέγχει ξανά την κατάσταση ακριβώς πριν στείλει email ή SMS, ώστε να μη ζητήσει χρήματα από πελάτη που μόλις πλήρωσε.
Χρήσιμα events είναι deposit_due, installment_due_soon, payment_overdue και payment_received. Κάθε event πρέπει να έχει μοναδικό κλειδί, για να μην αποσταλεί δύο φορές μετά από retry. Ο πελάτης χρειάζεται άμεσο link προς την παραγγελία και το ποσό, όχι ασαφές μήνυμα «υπάρχει εκκρεμότητα».
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry ξεκινάμε από τους πραγματικούς εμπορικούς όρους: ποιοι πελάτες δικαιούνται προκαταβολή, πότε δεσμεύεται απόθεμα, ποιος εγκρίνει αλλαγές και πώς ενημερώνεται το λογιστήριο. Έπειτα σχεδιάζουμε order ledger και payment schedule που διατηρούν κάθε συναλλαγή χωρίς πρόχειρες αλλαγές στο συνολικό ποσό.
Υλοποιούμε customer account με καθαρό υπόλοιπο και deadlines, admin εργαλεία για συμφωνία και exceptions, idempotent integrations με payment providers ή ERP και αυτοματισμούς που ελέγχουν την τρέχουσα κατάσταση πριν ενεργήσουν. Αυτή η προσέγγιση κάνει την Ai Foundry ισχυρό συνεργάτη για B2B e-shop με σύνθετους όρους, όπου μια απλή ένδειξη «μερικώς πληρωμένο» δεν αρκεί.
Checklist πριν το production
- Ξεχωρίζουν order total, payment schedule και transactions;
- Το υπόλοιπο υπολογίζεται από αμετάβλητα οικονομικά γεγονότα;
- Ο πελάτης βλέπει τι πληρώνει τώρα και πότε οφείλεται το υπόλοιπο;
- Υπάρχει πολιτική για αλλαγές μετά την προκαταβολή;
- Τα refunds συνδέονται με τις αρχικές μεθόδους πληρωμής;
- Η σύνδεση με ERP είναι idempotent;
- Οι τραπεζικές καταθέσεις έχουν μοναδικό reference;
- Οι υπενθυμίσεις ελέγχουν ξανά το υπόλοιπο πριν σταλούν;
Οι μερικές πληρωμές δεν είναι απλώς περισσότερα κουμπιά είσπραξης. Είναι οικονομική ροή που πρέπει να παραμένει κατανοητή από τον πελάτη, το e-shop και το λογιστήριο σε κάθε στάδιο.