Fatturazione ricorrente con Rails e ActiveMerchant: best practice, insidie, trucchi?

Question

Stiamo preparando per il rilascio di una grande applicazione web che è stata in sviluppo per l'anno scorso. Stiamo per avviare il processo di integrazione di ActiveMerchant per gestire le tariffe di abbonamento ricorrenti per il servizio.

Sto cercando qualsiasi consiglio in merito alle migliori pratiche in considerazione dei nostri requisiti (elencati di seguito) e di eventuali ulteriori segnalazioni per insidie ​​comuni o problemi specifici che dovrei prestare particolare attenzione. Il gateway di pagamento che utilizzeremo è PaymentExpress in quanto è uno dei pochi gateway supportati con fatturazione ricorrente e non ha condizioni speciali per le società che operano al di fuori degli Stati Uniti. L'attività dietro questa applicazione è basata fuori dal Regno Unito.

Gli utenti dell'applicazione creano un account con un sottodominio in cui possono accedere e personalizzare l'applicazione e i relativi dati. Qui di seguito sono alcuni dei requisiti/caratteristiche che potrebbero avere un effetto su come funziona la fatturazione:

• Tutti gli utenti ottengono una prova di 30 giorni
• Ci sono diversi piani, tra cui uno gratuito
• piani a prezzi più elevati hanno maggiori limiti sulla quantità di dati (ad es. utenti, progetti, ecc) che possono avere nel proprio account
• Il periodo di fatturazione sarà mensile, a partire dal periodo di prova
• Ci saranno sconti/codici promozionali per ottenere una percentuale di sconto rispetto al normale prezzo per un anno su piani, ecc.
• piano tariffario cambierà come caratteristiche sono aggiunte

ostacoli speciali Io posso prevedere saranno le cose tra cui le seguenti:

• Come gestire il downgrade quando violano i limiti del piano per i piani di livello inferiore.
• Comportamento quando le carte di credito scadono oi pagamenti non vengono eseguiti (è possibile applicare una modalità di sola lettura, forse)
• Quando i prezzi del piano cambiano, vogliamo onorare i prezzi precedenti per gli utenti esistenti per un periodo di tempo (ad esempio 6 mesi), quindi iniziare a caricare tariffe più elevate. Se il prezzo del piano diminuisce, avrà effetto immediato.

Altri consigli che potrebbero essere utili sarebbero qualsiasi cosa riguardante il flusso dell'applicazione. Come devono essere presentati i moduli di fatturazione all'utente? Quando devono essere richiesti i dati della carta di credito? Come devono essere spedite, archiviate e accessibili le fatture?

Devo rivelare che intendiamo basare molto sulla base di codice SaaSy. SaaSy è progettato per essere usato come app Rails separata che gestisce tutto il lato registrazione e gestione degli account. Tuttavia, questo non funziona per noi dal momento che non abbiamo mai pianificato questo dall'inizio e sarebbe un processo noioso per adattare la nostra applicazione al lavoro in questo modo. Di conseguenza, estraiamo codice e idee da SaaSy e li uniamo alla nostra app, un compito decisamente meno noioso.

Answer 1

RailsKits ha un Software as a Service kit che dovrebbe fare quello che ti serve. Ha un supporto integrato per prove gratuite, upgrade, downgrade, limiti del piano, ecc. E supporta PaymentExpress (e alcuni altri).

Ho studiato un po 'per un progetto che sto facendo, ma non l'ho ancora acquistato quindi non posso garantire per questo.Tuttavia, ho visto alcuni post sul blog che elogiano questo kit.

Mentre il RailsKit è relativamente poco costoso rispetto a quello che costerebbe implementare tutte le sue funzionalità da solo, ci sono un paio di versioni open source che mirano a realizzare la stessa cosa. Quello che ricordo in cima alla mia testa si chiama Freemium.

EDIT: Ho dimenticato di dire che Ryan Bates ha detto nel suo most recent Railscast che il suo prossimo episodio o due si occuperà di fatturazione ricorrente, quindi tenetelo d'occhio. Di solito fa un episodio a settimana, e i cinque che ha fatto dal 22 dicembre coprono tutti i pagamenti di gestione di diversi tipi.

Answer 2

Peepcode ha un PDF in vendita (70 pagine) che descrive i vari aspetti dell'elaborazione dei pagamenti e le pratiche del settore per questo. Può essere la pena di verificare:

http://peepcode.com/products/activemerchant-pdf

Answer 3

Una cosa che ho voluto aggiungere: tenere a mente che non è necessario utilizzare la funzione di fatturazione ricorrente che è costruito in gateway. In generale questi sistemi sono legacy e molto difficili da gestire, ci lasciamo viziare nel mondo dei rail.

Si ottiene molta più flessibilità semplicemente usandoli per uno scopo (per fatturare una carta di credito, e forse anche conservare le carte di credito per la conformità PCI). Quindi apporta la fatturazione ricorrente nella tua app per i rails con un cron job, un campo data per il pagamento e l'importo pagato da ogni persona (nel caso utilizzi un coupon) ecc.

Un piccolo esempio: a volte la gente cancellerà un abbonamento mensile a metà del mese. Vogliono assicurarsi che non dimentichino di cancellare prima del prossimo pagamento. La maggior parte della fatturazione ricorrente del gateway che ho visto chiuderà immediatamente l'account (o ti invierà un messaggio che lo indica). In realtà, l'utente ha pagato fino alla fine del mese e dovrebbe ricevere altre 2 settimane di accesso. Puoi eseguire questa operazione se hai eseguito il rollover della fatturazione ricorrente nei binari, ma non se stai utilizzando la fatturazione ricorrente del gateway. Solo un piccolo esempio.

Answer 4

Sono anche nel mezzo della creazione di un sito web basato su abbonamento e questi sono i nostri requisiti attuali. Possono essere utili per le migliori pratiche:

• Gli utenti potranno scegliere uno dei piani di abbonamento .
• Gli utenti saranno tenuti a inserire i dettagli della propria carta di credito per iscriversi allo piano scelto.
• Tutte le principali carte di credito e debito devono essere accettate come incluso Maestro e American Express.
• Ogni piano avrà una prova gratuita di 30 giorni in modo che le carte di credito degli utenti debbano essere corrisposte allo solo dopo la scadenza del periodo di 30 giorni . Tuttavia, la validità delle carte di credito deve essere verificata allo al momento dell'iscrizione.
• Gli utenti saranno inviati via email qualche giorno prima della loro carta di credito viene addebitata per notificare loro che essi saranno addebitati presto a meno che non si annullano il loro account . Se annullano il proprio account entro 30 giorni di prova gratuita, la loro carta di credito non deve essere addebitata.
• Dopo un periodo di prova gratuito, gli utenti verranno addebitati in anticipo per l'utilizzo del sistema da parte di , ovvero effettueranno il pagamento anticipato .
• Gli utenti verranno addebitati automaticamente ogni mese per il piano scelto. Ogni mese, agli utenti verrà inviata un'e-mail con qualche giorno di anticipo per notificare allo che verranno addebitati. Una volta effettuato il pagamento , gli utenti saranno e-mail con una fattura che mostra che il loro pagamento è stato ricevuto.
• Gli utenti potranno aggiornare o effettuare il downgrade dei loro account in qualsiasi momento. Quando gli utenti eseguono l'upgrade/downgrade, il loro costo di abbonamento successivo a sarà a la nuova tariffa. Gli utenti potranno utilizzare lo solo per eseguire il downgrade dei loro account su un piano in grado di gestire i propri dati. Per esempio , se attualmente hanno 10 progetti attivi non è possibile eseguire il downgrade di al piano di base perché il piano di base consente solo 5 progetti. Essi dovranno eliminare o archiviare 5 progetti prima di poter eseguire il downgrade in Basic.
• Gli utenti potranno accedere al proprio account e modificare o aggiornare i dettagli della carta di credito .
• Gli utenti saranno in grado di cancellare il proprio account in qualsiasi momento. Non ci saranno ulteriori costi di abbonamento dopo che un utente ha cancellato il proprio account. Tuttavia, gli utenti non saranno rimborsati per parte del mese in cui hanno già pagato .
• Tutte le parti del sistema di pagamento devono essere conformi allo standard PCI DSS ; incluso qualsiasi sistema di terze parti.
• Il sistema di pagamento deve supportare la notifica automatica e riprovare dei rinnovi dell'abbonamento non riusciti.
• Il sistema di pagamento deve supportare i buoni sconto con date di scadenza.
• dati della carta di credito non devono essere trattati da o memorizzati sui nostri server
• dovrebbero sempre essere trattati/conservati dal nostro 3a parte partner di elaborazione dei pagamenti. Noi non vogliamo la responsabilità per la protezione di questi dettagli e il rispetto delle norme e dei regolamenti legali .
• Gli utenti saranno in grado di accedere al loro conti e vedere una storia completa di fatturazione comprese le date e gli importi pagati . Sarà inoltre necessario essere in grado di accedere a un sistema per vedere i piani di pagamento dei clienti e la cronologia dei pagamenti . Questo sarà essenziale per il servizio clienti .

Abbiamo anche guardato allo http://chargify.com/ che sembra che potrebbe risparmiare un sacco di tempo per la codifica.