Facturation récurrente avec Rails et ActiveMerchant: meilleures pratiques, pièges, pièges?

Question

Nous sommes en préparation pour la libération d'une grande application web qui a été en développement pendant l'année écoulée. Nous sommes sur le point de commencer le processus d'intégration de ActiveMerchant pour gérer l'abonnement mensuel pour le service.

Je suis à la recherche pour obtenir des conseils concernant les meilleures pratiques compte tenu de nos exigences (voir ci-dessous) et les autres en heads-up pour les pièges les plus courants ou des questions spécifiques, je devrais être en accordant une attention particulière. La passerelle de paiement que nous allons utiliser est PaymentExpress que c'est l'une des rares prises en charge des passerelles qui a de facturation récurrente et n'ont pas de conditions particulières pour les entreprises opérant en dehors des états-unis. L'entreprise derrière cette application est basée au royaume-UNI.

Les utilisateurs de l'application créer un compte avec un sous-domaine où ils peuvent accéder et de personnaliser les applications et leurs données. Ci-dessous sont quelques-uns des exigences/caractéristiques qui pourraient avoir un effet sur la façon dont fonctionne la facturation:

• Tous les utilisateurs reçoivent un essai de 30 jours
• Il y a des plans différents, y compris un gratuit
• Prix plus élevés sur les plans ont plus de limites sur la quantité de données (par exemple, les utilisateurs, les projets, etc), ils peuvent avoir dans leur compte
• Période de facturation mensuelle, qui commence après le procès
• Il y aura des réductions et des codes promo pour obtenir un pourcentage sur le tarif normal pour un an sur les plans, etc.
• Prix Plan changera fonctionnalités sont ajoutées

Des obstacles spécifiques, je peux prévoir sera de choses, y compris les suivantes:

• Comment gérer le déclassement, lorsqu'ils violent les limites du plan pour le bas niveau des plans.
• Comportement lorsque les cartes de crédit expirent ou les paiements de ne pas passer à travers (mode lecture seule forcée, peut-être)
• Quand le plan des changements à la tarification, nous voulons honorer les anciens prix pour les utilisateurs existants pour une période de temps (par exemple 6 mois), puis démarrer le chargement des taux plus élevés. Si le plan de baisses de prix, il prendra effet immédiatement.

D'autres conseils qui pourraient être utiles serait tout ce qui concerne les flux de l'application. Comment doit-formules de facturation seront présentés à l'utilisateur? Quand doit-informations de carte de crédit est requis? Comment les factures doivent être envoyées, stockées et accessibles?

Je dois dire que nous avons l'intention à la base de beaucoup de la base de code hors SaaSy. SaaSy est conçu pour être utilisé séparément comme une application Rails qui gère l'ensemble de votre inscription et de gestion de compte côté des choses. Toutefois, cela ne fonctionne pas pour nous, car nous n'avons jamais prévu ce depuis le début, et il serait fastidieux de s'adapter à notre demande de travailler comme ça. Par conséquent, nous allons être en tirant des idées et code de SaaSy et en les fusionnant dans notre application, un nombre beaucoup moins fastidieuse.

Answer 1

Une chose que je voulais ajouter: gardez à l'esprit que vous n'avez pas besoin d'utiliser la facturation récurrente de la fonctionnalité est intégrée à la passerelle. En général, ces systèmes sont l'héritage et très difficile à traiter, nous obtenons gâtés dans les rails monde.

Vous obtenez beaucoup plus de flexibilité simplement les utiliser pour un but (pour le projet de loi de carte de crédit, et peut-être également de stocker des cartes de crédit pour la mise en conformité PCI). Ensuite, rouler votre propre facturation récurrente dans votre application rails avec un cron job, un champ de date pour le moment où ils sont payés par les, et le montant de chaque personne paie (dans le cas où ils ont utilisé un coupon), etc.

Un petit exemple: parfois, les gens vont annuler un abonnement mensuel au milieu du mois. Ils veulent s'assurer qu'ils ne pas oublier d'annuler avant le prochain paiement. La plupart de la passerelle de facturation récurrente que j'ai vu instantanément résilier le compte (ou de vous envoyer un message pour l'indiquer). En réalité, l'utilisateur a payé jusqu'à la fin du mois et devrait être donné 2 semaines de plus de l'accès. Vous pouvez le faire si vous avez roulé votre propre facturation récurrente dans les rails, mais pas si vous utilisez la passerelle de facturation récurrente. Juste un petit exemple.

Answer 2

RailsKits a un Logiciel de comme un Service kit qui devrait faire ce que vous avez besoin. Il a un support intégré pour les essais libres, la mise à niveau, le déclassement, plan de limites, etc., et il prend en charge PaymentExpress (et quelques autres).

J'ai fait des recherches un peu pour un projet que je suis en train de faire, mais je ne l'ai pas acheté encore donc je ne peux pas se porter garant pour elle. Cependant, j'ai vu quelques posts de blog de l'éloge de ce kit.

Alors que le RailsKit est relativement bon marché par rapport ce qu'il vous en coûterait pour mettre en œuvre l'ensemble de ses fonctionnalités vous, il ya un couple open source versions qui visent à faire la même chose. Celui dont je me souviens sur le dessus de ma tête est appelé Freemium.

EDIT: j'ai oublié de mentionner que Ryan Bates a dit dans son plus récent Railscast que son prochain épisode ou deux, traitera de la facturation récurrente, donc gardez un œil sur pour que. Il n'a généralement un épisode par semaine, et les cinq qu'il a fait depuis le 22 décembre, tous les couvrent le traitement des paiements de différents types.

Answer 3

Peepcode a un PDF à vendre (70 pages) qui détaille divers aspects du traitement des paiements et les pratiques de l’industrie dans ce domaine. Il peut être intéressant de vérifier:

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

Answer 4

Je suis également en train de mettre en place un abonnement site web et ce sont nos exigences actuelles. Ils peuvent vous aider concernant les meilleures pratiques:

• Les utilisateurs seront en mesure de choisir l'un de les plans d'abonnement.
• Les utilisateurs devront entrer leur détails de carte de crédit pour vous inscrire à leur plan choisi.
• Toutes les principales cartes de crédit et débit doit être accepté comme le maître et American Express.
• Chaque plan une gratuit de 30 jours essai de sorte que les utilisateurs de cartes de crédit devraient qu'après le délai de 30 jours fin de la période. Toutefois, la validité de cartes de crédit doit être vérifiée au au moment de l'inscription.
• Les utilisateurs seront envoyés par courriel quelques jours avant de leur carte de crédit est débitée pour les informer qu'ils seront chargée bientôt, à moins qu'ils annulent leur compte. Si ils annulent leur compte dans leur essai gratuit de 30 jours, leur carte de crédit ne doit pas être facturée.
• Après toute période d'essai gratuite, les utilisateurs sera facturé à l'avance pour leur l'utilisation du système - c'est à dire qu'ils seront pré-paiement.
• Les utilisateurs seront automatiquement facturés tous les mois pour leur plan choisi. Chaque mois, les utilisateurs seront envoyés à un e-mail quelques jours à l'avance pour informer - leur qu'ils seront facturés. Une fois le paiement a été effectué, les utilisateurs seront envoyé par courriel une facture indiquant que leur le paiement a été reçu.
• Les utilisateurs seront en mesure de mettre à niveau ou révisent à la baisse leurs comptes à tout moment. Lorsque les utilisateurs upgrade/downgrade, leur prochain prix de l'abonnement sera à le nouveau taux. Les utilisateurs pourront revoir à la baisse leurs comptes à un plan qui peuvent gérer leurs données. Pour exemple, si ils ont actuellement 10 projets actifs qu'ils ne peuvent pas downgrade le plan de Base, car la Base plan permet seulement 5 projets. Ils devrez la supprimer ou archiver 5 les projets avant qu'ils peuvent revenir à la Base.
• Les utilisateurs seront en mesure de se connecter à leur compte et de modifier ou de mettre à jour leurs détails de carte de crédit.
• Les utilisateurs seront en mesure d'annuler leur compte à tout moment. Il n'y aura pas en outre le prix de l'abonnement après un l'utilisateur a annulé leur compte. Cependant, les utilisateurs ne seront pas remboursés pour la partie du mois, ils ont déjà payées.
• Toutes les parties du système de paiement doit 100% PCI DSS; y compris un 3ème partie des systèmes.
• Le système de paiement doit prendre en charge notification automatique et tentative de échec des renouvellements d'abonnement.
• Le système de paiement doit prendre en charge des bons de réduction avec les dates de péremption.
• Détails de carte de crédit ne doit pas être traitées par ou stockées sur nos serveurs
• ils doivent toujours être traitées, stockées par notre 3ème partie traitement de paiement partenaire. Nous n'avons pas voulez de la responsabilité de garantir ces détails et de s'y conformer règles juridiques et de la réglementation.
• Les utilisateurs seront en mesure de se connecter à leur comptes et de voir plein de facturation l'histoire, y compris les dates et les montants payé. Nous aurons aussi besoin d'être en mesure de se connecter à un système pour voir la clientèle des plans de paiement et de paiement l'histoire. Ce sera indispensable pour service à la clientèle.

Nous avons également été à la recherche à http://chargify.com/ qui ressemble à cela pourrait sauver beaucoup de temps en programmation.