Gestione delle sottoscrizioni, dei saldi e delle modifiche al piano tariffario [chiuso]

Preambolo Il
mio obiettivo è creare codice riutilizzabile per più progetti (e anche pubblicarlo su github) per gestire gli abbonamenti. Conosco i fornitori di fatturazione stripe e ricorrenti, ma non è questo l'obiettivo del modulo. Dovrebbe essere solo un wrapper / helper per il calcolo del saldo del conto, facili notifiche per rinnovare un abbonamento e gestire i calcoli dei prezzi.

Esistono paesi in cui non è possibile utilizzare la fatturazione ricorrente a causa del fatto che i fornitori o le possibilità di pagamento hanno un supporto scarso o assente o sono troppo costosi (micropagamenti). E ci sono persone che non vogliono utilizzare la fatturazione ricorrente ma pagano la fattura manualmente / vendendo una fattura alla fine dell'anno. Quindi, per favore, non suggerire servizi di fatturazione ricorrenti, ricorrenti o simili su paypal.

Situazione
Supponiamo che tu abbia un modello che può abbonarsi a un piano di abbonamento (ad es User.). Questo modello ha un campo che memorizza l'identificatore di un piano di abbonamento a cui è attualmente abbonato. Quindi, ad ogni modifica del piano, la modifica viene registrata.

Esiste un modello (ad es. SubscriptionPlanChanges) Con i seguenti campi che registrano le modifiche menzionate:

• subscriberrelativo al modello di abbonamento ( Userin questo caso)
• from_plan definendo l'identificatore del piano che il modello aveva prima della modifica
• to_plan definendo l'identificatore del piano che il modello ha selezionato ora
• created_at è un campo data-ora in cui è memorizzata la modifica
• valid_until memorizza la data fino a quando l'abbonamento effettivo è valido
• paid_at è anche un campo data-ora che definisce se (e quando) l'abbonamento è stato pagato

Certo, questo layout è discutibile.

Domanda sul saldo del conto
Quando un utente modifica il proprio piano di abbonamento, devo confrontare i campi del piano, ottenere i prezzi e calcolare la detrazione per il nuovo piano in base al piano corrente valid_untile al suo prezzo. Dì: Ti sei iscritto per un anno del piano A ma dopo 6 mesi esegui l'upgrade al piano B, in modo da ottenere una detrazione della metà del prezzo pagato per i 6 mesi del piano A.

Quello che mi chiedo: se un utente, ad esempio, passa al piano gratuito, ha un credito che può essere dedotto se l'utente desidera passare nuovamente. Vuoi memorizzare tale valore in un campo aggiuntivo o calcolare ogni volta tutti i record relativi a quell'utente? Vuoi aggiungere / modificare qualcosa sul layout della tabella?

Domanda di facile comprensibilità
Quando arriva la fine di un periodo di abbonamento, l'utente viene avvisato e ha la possibilità di rinnovare l'abbonamento pagando di nuovo. Il modo più semplice sarebbe semplicemente aggiornare paid_ate valid_untilcon nuove opzioni di abbonamento. Tuttavia, non sono sicuro se memorizzi tutti i dati di cui qualcuno potrebbe aver bisogno, come una cronologia di pagamenti / abbonamenti.

Un'altra opzione sarebbe quella di creare un record aggiuntivo per questo, dove from_plane to_planstanno avendo lo stesso identificatore (che simboleggia quindi "nessuna modifica"). Ma ciò non interferirebbe in qualche modo con il calcolo del saldo del conto?

Se qualcuno potesse indicarmi la giusta direzione riguardo alle logiche che gestiscono tali abbonamenti, lo apprezzerei molto.

AGGIORNAMENTO
Grazie per l'aiuto ormai. Penso che la mia domanda fosse troppo vaga, quindi cercherò di essere più preciso usando meno astrazioni. Sfortunatamente, non sono ancora riuscito a risolvere il mio problema.

Il caso A
User può essere selezionato Subscription Plan A. Questo attualmente memorizza un SubscriptionPlanChangeper tenerne traccia. Dopo, ad esempio, 5 mesi, Useraggiorna il suo abbonamento a Subscription Plan B. Quindi paga il prezzo per il suo nuovo abbonamento, deducendo il prezzo del piano a per i 7 mesi inutilizzati.

Caso B
Dopo 3 mesi, Usertorna al suo Subscription Plan A. Non deve pagare, ma riceve un saldo per questo in modo che, al termine dell'abbonamento, venga detratto tale saldo per il suo nuovo abbonamento.

Il caso C
User può selezionare un piano di abbonamento per un servizio secondario con piani di abbonamento indipendenti. Lo stesso Case Ae Case Bpuò richiedere l'abbonamento al servizio secondario.

_Case D_ L'utente annulla uno dei suoi abbonamenti. Ciò si traduce in una ricarica del suo equilibrio.

La mia domanda (almeno attualmente) dipende principalmente da come archiviare correttamente quei dati in modo da poter riprodurre una cronologia degli abbonamenti per l'analisi aziendale e calcolare i saldi, ottenere pagamenti in sospeso in base agli abbonamenti ecc.

Inoltre, non sono sicuro se la bilancia debba essere archiviata, ad esempio nel modello stesso degli utenti, o se non è memorizzata, ma può essere calcolata in qualsiasi momento in base ai dati / cronologia memorizzati.

Alcune cose da notare, anche se non credo che dovrebbero introdurre problemi:

• Non deve essere un User, potrebbe essere qualsiasi cosa, ecco perché Subscriberè polimorfico
• Plansnon devono necessariamente essere piani, ma potrebbero essere ad esempio Magazinescome menzionati. Questo è quello che ho descritto con procedimento C e Caso D .

Sfortunatamente, la risposta a un problema complicato è generalmente complicata. Il mio consiglio sarebbe di salvare solo le informazioni rilevanti, quindi utilizzare un modello per costruire l'immagine più grande.

In altre parole, la tabella SubscriptionPlanChanges avrebbe le seguenti informazioni per la sua chiave:

• abbonato
• Piano
• valido dal

In questo modo, si consentono più piani per lo stesso abbonato che possono sovrapporsi. Altri campi includono:

• valido fino a
• pagato fino al
• tasso (anche 0 se libero)

Si noti che non esiste un "piano da" o "piano a". Sebbene tu possa averli, le informazioni sono superflue e possono essere calcolate da sole (la memorizzazione di tali informazioni significa che hai il compito aggiuntivo di mantenerle coerenti). Quando inizia un nuovo piano, anziché dover modificare i piani esistenti, li lasci e aggiungi semplicemente un nuovo record. Se esiste un altro piano sovrapposto dopo il nuovo piano, è possibile decidere di volerlo eliminare (più intuitivo in questo modo). Quando carichi questi piani per un abbonato, li ordini in base alla data "valida da".

Una volta ottenuto questo, calcolare il credito di un utente è relativamente semplice. Se due piani non possono sovrapporsi, è sufficiente prendere la minore tra due date tra la data "valida fino a" del piano precedente e la "valida da" del piano corrente per determinare la data di fine. La data di inizio è la maggiore delle due date tra la data "valida da" e la data "pagato fino a" (se definita). Il pagamento (o credito) può quindi essere calcolato sulla tariffa moltiplicata per l'intervallo di tempo tra le date di inizio e fine sopra menzionate di quel piano.

In questo modo, in teoria puoi calcolare tutto ciò che avresti bisogno di sapere. Vorrei sconsigliare di provare a salvare i valori calcolati, poiché cambierebbe quando un record esistente viene modificato, aggiunto o eliminato.

Le variazioni della modalità di calcolo di questi valori possono essere gestite aggiungendo un campo di tipo aggiuntivo. Nel tuo codice, potresti creare gestori speciali per gestire la logica del calcolo di piani particolari al fine di mantenere il tuo algoritmo principale relativamente libero da calcoli complicati. Meglio ancora se riesci a creare un gestore per il caso in cui non viene specificato alcun tipo, quindi tutto ciò che devi fare è chiamare il gestore appropriato in base al suo tipo per effettuare qualsiasi tipo di calcolo richiesto.

Spero che risponda alla tua domanda.

Oltre alla risposta di cui sopra, creerei una tabella con crediti, in cui un credito equivarrebbe alla valuta corrente. Ogni volta che l'utente passa a un'alternativa più economica, il saldo non utilizzato viene inserito come credito. Ogni volta che l'utente ha qualcosa da pagare, devi prima utilizzare i crediti e chiedere il pagamento solo se i crediti si esauriscono o non esistono. Se si utilizza questa alternativa, creare la tabella come un elenco di transazioni per poter riprodurre lo scenario di utilizzo in caso di controversia. Esempio:

ID, UserId, TransactionDate, Credit (positivo quando si danno crediti all'utente e negativo quando l'utente utilizza il credito)

Basta sommare i crediti per l'utente per mostrargli il saldo.

Spero che ti sia utile ...