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

Question

Stiamo preparando il rilascio di una grande applicazione Web che è stata in sviluppo nell'ultimo anno. Stiamo per iniziare il processo di integrazione di ActiveMerchant per gestire le commissioni di abbonamento ricorrenti per il servizio.

Sto cercando qualche consiglio in merito alle migliori pratiche considerando i nostri requisiti (elencati di seguito) e qualsiasi ulteriore avvertimento per insidie ??comuni o problemi specifici che dovrei tenere in considerazione. Il gateway di pagamento che utilizzeremo è PaymentExpress in quanto è uno dei pochi gateway supportati con fatturazione ricorrente e non non hanno condizioni speciali per le aziende che operano al di fuori degli Stati Uniti. Il business alla base di questa applicazione ha sede nel Regno Unito.

Gli utenti dell'applicazione creano un account con un sottodominio in cui possono accedere e personalizzare l'applicazione e i loro dati. Di seguito sono riportati alcuni dei requisiti / funzionalità che potrebbero influire sul funzionamento della fatturazione:

• Tutti gli utenti hanno una prova di 30 giorni
• Esistono piani diversi, incluso uno gratuito
• I piani a prezzo più elevato hanno limiti più elevati sulla quantità di dati (ad es. utenti, progetti, ecc.) che possono avere nel proprio account
• Il periodo di fatturazione sarà mensile, a partire dalla versione di prova
• Ci saranno sconti / codici coupon per ottenere una percentuale dal prezzo normale per un anno sui piani, ecc.
• I prezzi del piano cambieranno con l'aggiunta delle funzionalità

Gli ostacoli specifici che posso prevedere saranno le cose tra cui:

• Come gestire il downgrade quando violano i limiti del piano per i piani di livello inferiore.
• Comportamento in caso di scadenza delle carte di credito o di mancato pagamento (forse viene applicata una modalità di sola lettura)
• Quando i prezzi del piano cambiano, vogliamo rispettare i prezzi precedenti per gli utenti esistenti per un periodo di tempo (come 6 mesi), quindi iniziare a addebitare tariffe più elevate. Se il prezzo del piano diminuisce, avrà effetto immediato.

Altri consigli che potrebbero essere utili sarebbero qualcosa riguardo al flusso dell'applicazione. Come devono essere presentati all'utente i moduli di fatturazione? Quando devono essere richiesti i dati della carta di credito? Come devono essere inviate, archiviate e accessibili le fatture?

Dovrei rivelare che intendiamo basare gran parte del codice su SaaSy . SaaSy è progettato per essere utilizzato come app Rails separata che gestisce tutto il lato dell'iscrizione e della gestione dell'account. Tuttavia, questo non funziona per noi dal momento che non abbiamo mai pianificato questo dall'inizio e sarebbe un processo noioso adattare la nostra applicazione per funzionare in questo modo. Di conseguenza, estrarremo codice e idee da SaaSy e li fonderemo nella nostra app, un compito notevolmente meno noioso.

Answer 1

RailsKits ha un Software as a Service kit che dovrebbe fare ciò di cui hai bisogno. Ha un supporto integrato per prove gratuite, upgrade, downgrade, limiti di piano, ecc. E supporta PaymentExpress (e alcuni altri).

L'ho cercato un po 'per un progetto che sto realizzando, ma non l'ho ancora acquistato, quindi non posso garantirlo. Tuttavia, ho visto alcuni post sul blog che elogiano questo kit.

Mentre RailsKit è relativamente poco costoso rispetto a quanto ti 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 dalla cima della mia testa si chiama Freemium .

EDIT: ho dimenticato di dire che Ryan Bates ha detto nel suo Railscast più recente che il suo prossimo episodio o due affronterà la fatturazione ricorrente, quindi tienilo d'occhio. Di solito fa un episodio alla settimana e i cinque che ha fatto dal 22 dicembre coprono tutti i pagamenti di gestione di tipi diversi.

Answer 2

Una cosa che volevo aggiungere: tieni presente che non è necessario utilizzare la funzione di fatturazione ricorrente integrata nel gateway. In generale questi sistemi sono legacy e molto difficili da gestire, ci viziamo nel mondo delle rotaie.

Ottieni molta più flessibilità semplicemente usandoli per uno scopo (fatturare una carta di credito e forse anche memorizzare carte di credito per la conformità PCI). Quindi ruota la tua fatturazione ricorrente nella tua app rails con un lavoro cron, un campo data per quando vengono pagati e l'importo che ogni persona sta pagando (nel caso in cui abbiano usato un coupon) ecc.

Un piccolo esempio: a volte le persone annullano un abbonamento mensile a metà mese. Vogliono assicurarsi di non dimenticare di annullare 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 indica questo). In realtà, l'utente ha pagato fino alla fine del mese e dovrebbe ricevere altre 2 settimane di accesso. È possibile eseguire questa operazione se la fatturazione ricorrente è stata distribuita su rotaia, ma non se si utilizza la fatturazione ricorrente del gateway. Solo un piccolo esempio.

Answer 3

Peepcode ha un PDF in vendita (70 pagine) che descrive in dettaglio vari aspetti dell'elaborazione dei pagamenti e le pratiche del settore per questo. Potrebbe valere la pena dare un'occhiata:

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

Answer 4

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

• Gli utenti potranno scegliere uno di i piani di abbonamento.
• Gli utenti dovranno inserire il proprio dettagli della carta di credito a cui iscriversi il loro piano scelto.
• Devono essere tutte le principali carte di credito e debito essere accettato tra cui Maestro e American Express.
• Ogni piano avrà una libera di 30 giorni prova quindi le carte di credito degli utenti dovrebbero addebito solo dopo i 30 giorni il periodo scade. Tuttavia, la validità delle carte di credito deve essere verificato presso il momento della registrazione.
• Gli utenti riceveranno un'email entro pochi giorni prima dell'addebito sulla loro carta di credito per avvisare che lo saranno addebitato presto a meno che non annullino il loro account. Se cancellano il loro account nella loro prova gratuita di 30 giorni, la loro la carta di credito non deve essere addebitata.
• Dopo qualsiasi periodo di prova gratuito, gli utenti verrà addebitato in anticipo per il loro uso del sistema - cioè lo faranno pre-pay.
• Gli utenti verranno addebitati automaticamente ogni mese per il piano scelto. Ogni mese, agli utenti verrà inviato un e-mail con qualche giorno di anticipo per avvisare loro che verranno addebitati. Una volta il pagamento è stato effettuato, gli utenti lo saranno inviato una fattura via e-mail che mostra che il loro il pagamento è stato ricevuto.
• Gli utenti saranno in grado di aggiornare o eseguire il downgrade dei propri account in qualsiasi momento. Quando gli utenti eseguono l'aggiornamento / downgrade, il loro il prossimo costo di abbonamento sarà a la nuova tariffa. Gli utenti potranno solo per eseguire il downgrade dei loro account a un piano che possono gestire i loro dati. Per esempio, se attualmente ne hanno 10 progetti attivi che non possono effettuare il downgrade al piano Basic perché Basic piano consente solo 5 progetti. Essi dovrà eliminare o archiviare 5 progetti davanti a te che possono downgrade a Basic.
• Gli utenti potranno accedere al proprio account e modificare o aggiornare il loro dettagli della carta di credito.
• Gli utenti saranno in grado di annullare il loro account in qualsiasi momento. Non ci sarà ulteriori spese di abbonamento dopo a l'utente ha cancellato il proprio account. Tuttavia, gli utenti non saranno rimborsati per parte del mese che hanno già pagato.
• Tutte le parti del sistema di pagamento devono essere conforme al 100% PCI DSS; Compreso eventuali sistemi di terze parti.
• Il sistema di pagamento deve supportare notifica automatica e nuovo tentativo di rinnovi di abbonamento non riusciti.
• Il sistema di pagamento deve supportare buoni sconto con date di scadenza.
• I dettagli della carta di credito non devono essere elaborati o archiviati sui nostri server
• devono essere sempre elaborati / archiviati dalla nostra terza parte partner per l'elaborazione dei pagamenti. Noi non vuole la responsabilità per la sicurezza questi dettagli e il rispetto norme e regolamenti legali.
• Gli utenti potranno accedere al proprio conti e vedere una fatturazione completa cronologia comprese date e importi pagato. Dovremo anche essere in grado di accedere a un sistema per vedere piani di pagamento del cliente e pagamento storia. Questo sarà essenziale per servizio clienti.

Abbiamo anche esaminato http://chargify.com/ che sembra che potrebbe salvare un molto tempo di programmazione.