Πώς να ρυθμίσετε την αυτόματη ανανέωση υπολοίπου στο SMM panel μέσω API

Τι να προετοιμάσετε πριν από τη ρύθμιση της αυτόματης ανανέωσης

Η αυτόματη ανανέωση συνδέει το υπόλοιπο του SMM panel με μια υπηρεσία πληρωμών ή εσωτερική χρέωση. Η υπηρεσία ελέγχει το υπόλοιπο, δημιουργεί πληρωμή όταν επιτευχθεί το καθορισμένο όριο και πιστώνει τα χρήματα μόνο αφού επιβεβαιωθεί η πληρωμή. Για τη λειτουργία απαιτούνται η τεκμηρίωση του API του panel, πρόσβαση στο API πληρωμών, ξεχωριστά κλειδιά για το περιβάλλον δοκιμών και το περιβάλλον παραγωγής, καθώς και αρχείο καταγραφής όλων των συναλλαγών.

Πριν από την ανάπτυξη, ελέγξτε αν το API του panel μπορεί να επιστρέφει το υπόλοιπο, να δέχεται αίτημα πίστωσης, να εμφανίζει το ιστορικό ανανεώσεων και να δέχεται εξωτερικό αναγνωριστικό συναλλαγής. Αν το panel δεν υποστηρίζει πίστωση μέσω API, η αυτοματοποίηση θα μπορεί μόνο να δημιουργήσει αίτημα ή να στείλει ειδοποίηση σε χειριστή. Το μειονέκτημα αυτής της επιλογής είναι ότι τα χρήματα θα πρέπει ούτως ή άλλως να κατατεθούν χειροκίνητα.

Διαχωρίστε τον έλεγχο υπολοίπου από την απόφαση πληρωμής

Ο έλεγχος του υπολοίπου καλό είναι να εκτελείται ως ξεχωριστή εργασία βάσει χρονοδιαγράμματος. Λαμβάνει το υπόλοιπο, το συγκρίνει με το όριο και μεταβιβάζει το αποτέλεσμα στον χειριστή ανανέωσης. Μη δημιουργείτε πληρωμή απευθείας τη στιγμή της απόκρισης του API χωρίς έλεγχο των τρεχουσών εκκρεμών συναλλαγών: παράλληλες εργασίες μπορεί να δουν το ίδιο χαμηλό υπόλοιπο και να δημιουργήσουν πολλαπλές πληρωμές.

Πριν από μια νέα πληρωμή, ο χειριστής πρέπει να ελέγξει αν υπάρχει συναλλαγή με κατάσταση «δημιουργήθηκε», «αναμένει πληρωμή» ή «επιβεβαιώνεται». Αν υπάρχει τέτοια εγγραφή, δεν ξεκινά νέα προσπάθεια μέχρι να ολοκληρωθεί ο συμψηφισμός. Το μειονέκτημα της διαδοχικής επεξεργασίας είναι ότι με αργή απόκριση του εξωτερικού API η ανανέωση μπορεί να ξεκινήσει αργότερα από ό,τι με πολλαπλά παράλληλα αιτήματα.

Επιλέξτε όριο και λογική ποσού ανανέωσης

Το όριο υπολοίπου επιλέγεται με περιθώριο για ενεργές παραγγελίες, ουρά στους προμηθευτές και καθυστερήσεις πληρωμών. Για κανάλι με ανομοιόμορφη δραστηριότητα, το να βασίζεστε μόνο στη μέση κατανάλωση είναι ριψοκίνδυνο: μετά από stream, εκκίνηση διαφήμισης ή μαζική παραγγελία οι χρεώσεις μπορεί να αυξηθούν απότομα. Ξεχωριστά ορίζεται κρίσιμο επίπεδο, στο οποίο έρχεται ειδοποίηση, αλλά η πληρωμή δεν δημιουργείται απαραίτητα αυτόματα.

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

Ρυθμίστε οικονομικούς περιορισμούς ξεχωριστά από το όριο

Το όριο απαντά μόνο στο ερώτημα πότε επιτρέπεται στο σύστημα να ξεκινήσει τη διαδικασία ανανέωσης. Οι περιορισμοί απαντούν σε άλλο ερώτημα: πόσα χρήματα επιτρέπεται να χρεώσει. Ορίστε μέγιστο ποσό μίας συναλλαγής, συνολικό όριο για την περίοδο και επιτρεπόμενο υπόλοιπο μετά την πίστωση. Αυτοί οι κανόνες ελέγχονται πριν από τη δημιουργία της πληρωμής, όχι μετά την πληρωμή της.

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

Δημιουργήστε ξεχωριστά κλειδιά και προστατέψτε την πρόσβαση

Για το script αυτόματης ανανέωσης χρησιμοποιήστε ξεχωριστά κλειδιά API με ελάχιστα δικαιώματα: ανάγνωση υπολοίπου, δημιουργία πληρωμής, έλεγχος κατάστασης και πίστωση επιβεβαιωμένης συναλλαγής. Πρόσβαση σε χρήστες, ρυθμίσεις υπηρεσιών, παραγγελίες και ανάληψη χρημάτων δεν χρειάζεται για ένα τέτοιο κλειδί. Αν η υπηρεσία υποστηρίζει περιορισμό βάσει διεύθυνσης IP, επιτρέψτε αιτήματα μόνο από τον διακομιστή της ενσωμάτωσης.

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

Δημιουργήστε πληρωμή με μοναδικό αναγνωριστικό

Σε κάθε ανανέωση εκχωρείται εσωτερικό αναγνωριστικό πριν από την κλήση του API πληρωμών. Αποθηκεύεται στο αρχείο καταγραφής και μεταβιβάζεται ως κλειδί ιδιοδυναμικότητας ή εξωτερικός αριθμός συναλλαγής. Σε περίπτωση δικτυακού χρονικού ορίου, το ίδιο αίτημα μπορεί να επαναληφθεί με το ίδιο αναγνωριστικό: η υπηρεσία πληρωμών πρέπει να επιστρέψει την ήδη δημιουργημένη συναλλαγή και όχι να χρεώσει ξανά τα χρήματα.

Παρακάτω ακολουθεί ένα γενικό παράδειγμα αιτήματος. Αντικαταστήστε τα ονόματα πεδίων και τις διευθύνσεις με τις τιμές από την τεκμηρίωση του συγκεκριμένου παρόχου. Η μεταβλητή PAYMENT_ID περιέχει ένα εκ των προτέρων δημιουργημένο μοναδικό ID, και η CALLBACK_URL οδηγεί στον χειριστή webhooks.

curl -X POST "$PAYMENT_API_URL/payments" \
-H "Authorization: Bearer $PAYMENT_API_KEY" \
-H "Idempotency-Key: $PAYMENT_ID" \
-H "Content-Type: application/json" \
-d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID","callback_url":"$CALLBACK_URL"}'

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

Ελέγχετε το υπόλοιπο και αποθηκεύετε την κατάσταση της συναλλαγής

Το αίτημα υπολοίπου πρέπει να εκτελείται πριν από την απόφαση για νέα ανανέωση και μετά από επιτυχή πίστωση. Ένα γενικό αίτημα μπορεί να έχει ως εξής: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY". Στην απόκριση αποθηκεύστε όχι μόνο το ποσό, αλλά και τον χρόνο ελέγχου, ώστε να μην λαμβάνετε αποφάσεις βάσει παρωχημένων δεδομένων.

Για κάθε συναλλαγή τηρείτε εγγραφή με το εσωτερικό ID, το ID πληρωμής στον πάροχο, το ποσό, το νόμισμα, τον χρόνο δημιουργίας, την κατάσταση, τις αποκρίσεις του API και την αιτία σφάλματος. Μια κατάλληλη ακολουθία καταστάσεων: «δημιουργήθηκε», «αναμένει πληρωμή», «πληρώθηκε», «πιστώνεται», «πιστώθηκε», «ακυρώθηκε», «απαιτεί έλεγχο».

Η πίστωση στο panel επιτρέπεται μόνο για επιβεβαιωμένη και μη επεξεργασμένη ακόμη πληρωμή. Μην αλλάζετε καταστάσεις χωρίς ιστορικό: σε περίπτωση διαφωνίας πρέπει να φαίνεται ποιο αίτημα στάλθηκε και γιατί άλλαξε η συναλλαγή. Το μειονέκτημα του λεπτομερούς αρχείου καταγραφής είναι ότι μπορεί να περιέχει ευαίσθητα δεδομένα, γι' αυτό η πρόσβαση σε αυτό περιορίζεται.

Δέχεστε το webhook και επαληθεύετε την κατάσταση της πληρωμής

Η σελίδα επιτυχημένης πληρωμής και η ανακατεύθυνση του χρήστη δεν επιβεβαιώνουν την είσπραξη των χρημάτων. Επιβεβαίωση αποτελεί το webhook από την υπηρεσία πληρωμών ή ο επανέλεγχος της κατάστασης μέσω του API της. Κατά τη λήψη του webhook ελέγξτε την υπογραφή, τον χρόνο αποστολής, το ID πληρωμής, το εξωτερικό ID, το ποσό και το νόμισμα. Μόνο μετά από αυτό μεταφέρετε τη συναλλαγή σε κατάσταση επιβεβαιωμένης πληρωμής.

Μετά τον έλεγχο του webhook είναι χρήσιμο να ζητήσετε την τρέχουσα κατάσταση της πληρωμής από τον πάροχο. Για παράδειγμα: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY". Συγκρίνετε την κατάσταση με τα δεδομένα του αρχείου καταγραφής και στη συνέχεια στείλτε αίτημα πίστωσης στο SMM panel με το ίδιο εσωτερικό ID.

Ένα επαναλαμβανόμενο webhook δεν πρέπει να δημιουργεί δεύτερη πίστωση. Ο χειριστής βρίσκει τη συναλλαγή από το εξωτερικό ID, βλέπει την κατάσταση «πιστώθηκε» και επιστρέφει επιτυχή απόκριση χωρίς νέες ενέργειες. Το μειονέκτημα των webhooks είναι ότι μπορεί να καθυστερήσουν ή να μην φτάσουν αν ο χειριστής ήταν μη διαθέσιμος.

Χειριστείτε χρονικά όρια, επαναλήψεις και κολλημένες πληρωμές

Σε περίπτωση χρονικού ορίου μετά τη δημιουργία πληρωμής, μη στέλνετε νέο αίτημα με διαφορετικό ID. Πρώτα βρείτε τη συναλλαγή από το εσωτερικό αναγνωριστικό ή επαναλάβετε το αίτημα με το ίδιο κλειδί ιδιοδυναμικότητας. Αν ο πάροχος αποδέχτηκε το αρχικό αίτημα, θα επιστρέψει την υπάρχουσα πληρωμή. Αυτό προστατεύει από διπλή χρέωση σε περίπτωση διακοπής σύνδεσης.

Αν το webhook δεν έφτασε εντός καθορισμένου χρόνου, μια εργασία παρασκηνίου ζητά την κατάσταση της πληρωμής μέσω API. Οι επανέλεγχοι γίνονται με αυξανόμενη παύση και περιορισμένο αριθμό προσπαθειών, ώστε να μην υπερφορτώνονται το API και το αρχείο καταγραφής. Μια συναλλαγή που παραμένει για πολύ σε αναμονή μεταφέρεται σε χειροκίνητο έλεγχο και δεν θεωρείται ακυρωμένη χωρίς συμψηφισμό.

Σε αποκρίσεις για προσωρινό σφάλμα δικτύου ή μη διαθεσιμότητα του API, οι επαναλήψεις είναι αποδεκτές. Σε απόρριψη πληρωμής, λανθασμένο ποσό, μη έγκυρη υπογραφή webhook ή υπέρβαση ορίου, δεν αξίζει να επαναλαμβάνεται το αίτημα αυτόματα. Το μειονέκτημα των επαναλήψεων είναι ότι περιπλέκουν τη λογική καταστάσεων και μπορεί να δημιουργήσουν επιπλέον φόρτο σε μαζική βλάβη του παρόχου.

Πιστώστε την επιβεβαιωμένη πληρωμή στο SMM panel

Πριν από την πίστωση, ο χειριστής ελέγχει ξανά: το ποσό δεν υπερβαίνει το όριο, το νόμισμα συμπίπτει, η συναλλαγή δεν έχει ακυρωθεί και η κατάστασή της δεν είναι ακόμη «πιστώθηκε». Στο αίτημα μεταβιβάζονται το ποσό και το εξωτερικό αναγνωριστικό της πληρωμής. Αν το API του panel υποστηρίζει κλειδί ιδιοδυναμικότητας, χρησιμοποιήστε το ίδιο εσωτερικό ID συναλλαγής.

Γενική μορφή αιτήματος: curl -X POST "$PANEL_API_URL/balance/topups" -H "Authorization: Bearer $PANEL_API_KEY" -H "Content-Type: application/json" -H "Idempotency-Key: $PAYMENT_ID" -d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID"}'

Μετά την απόκριση του panel, ζητήστε ξανά το υπόλοιπο και αποθηκεύστε το αποτέλεσμα στο αρχείο καταγραφής. Αν τα χρήματα χρεώθηκαν από την υπηρεσία πληρωμών αλλά το API του panel επέστρεψε σφάλμα, μη δημιουργήσετε νέα πληρωμή. Η συναλλαγή παραμένει σε κατάσταση «απαιτεί έλεγχο» μέχρι τη νέα προσπάθεια πίστωσης ή τον χειροκίνητο συμψηφισμό. Το μειονέκτημα αυτού του προσεκτικού σχήματος είναι ότι το υπόλοιπο μπορεί να μην ανανεωθεί προσωρινά αυτόματα.

Προσθέστε ειδοποιήσεις, διακόπτη και έλεγχο εκκίνησης

Οι ειδοποιήσεις χρειάζονται για αποκλίσεις: το υπόλοιπο έπεσε κάτω από το κρίσιμο επίπεδο, η πληρωμή απορρίφθηκε, το webhook δεν ελήφθη, το όριο ξεπεράστηκε, το API δεν είναι διαθέσιμο ή η συναλλαγή απαιτεί χειροκίνητο έλεγχο. Στο μήνυμα αρκεί να αναφέρονται το εσωτερικό ID, η κατάσταση και η αιτία. Μην συμπεριλαμβάνετε σε αυτό κλειδιά API, υπογραφές webhook και στοιχεία πληρωμής.

Αφήστε ξεχωριστό διακόπτη αυτόματης ανανέωσης χωρίς να αφαιρέσετε την ενσωμάτωση. Χρειάζεται κατά την αλλαγή παρόχου, σε τεχνικές εργασίες, σε υποψία σφάλματος ή σε απότομη αλλαγή εξόδων. Το μειονέκτημα του διακόπτη είναι προφανές: αν δεν τον ενεργοποιήσετε ξανά μετά τις εργασίες, το υπόλοιπο μπορεί να εξαντληθεί κατά τη διάρκεια ενεργών παραγγελιών.

Λίστα ελέγχου πριν από την ενεργοποίηση της αυτόματης ανανέωσης

• Ο έλεγχος υπολοίπου δεν δημιουργεί πληρωμή όσο υπάρχει εκκρεμής συναλλαγή.
• Για κάθε πληρωμή δημιουργείται μοναδικό εσωτερικό ID και κλειδί ιδιοδυναμικότητας.
• Έχουν ρυθμιστεί όρια για μία συναλλαγή και για την επιλεγμένη περίοδο.
• Τα webhooks ελέγχονται βάσει υπογραφής, ποσού, νομίσματος και αναγνωριστικού.
• Σε απουσία webhook ξεκινά επανέλεγχος κατάστασης μέσω API.
• Το χρονικό όριο δεν οδηγεί στη δημιουργία δεύτερης πληρωμής πριν από τον έλεγχο της πρώτης.
• Η πίστωση στο panel εκτελείται μία φορά και καταγράφεται στο αρχείο καταγραφής.
• Η δοκιμαστική λειτουργία έχει ελεγχθεί σε επιτυχία, απόρριψη, διπλό webhook και μη διαθεσιμότητα API.