Alternatives to Zuora

Dear StackShare Community,

I am seeking inspiration on creating a billing & subscription stack and came across this wonderful website and community.

From what I understood so far, I need something like Stripe or Braintree to collect payments without dealing with PCI compliance or setting up merchant accounts, etc... Additionally, services like Chargebee, Recurly, Chargify, etc. are said to make life easier when dealing with recurring billing.

Stated below, I've tried to give you some context on what I want to achieve. I am very curious about your ideas and how you'd configure an optimal stack.

Project context (very high level):

• Loyalty program for local merchants (stores, restaurants,...).

• Customers support their community and merchants by shopping local.

• Merchants grant points to customers based on a customer's value spent in a store, restaurant, etc.

• Customers can redeem their points at any participating merchant.

Billing / Subscription scenarios to be considered:

(affecting merchants only)

One-time setup fee

• What: Merchant pays a setup fee by signing up for the service

• Where: Order placed on the website

Monthly retainer fee

• What: Merchant pays a monthly recurring retainer for the service.

• Where: Order placed on the website

Manually initiated payment

• What: Merchant initiates a payment to top up his virtual points wallet. E.g. pays 100 USD to top up 100000 points which then can be used by the merchant for granting points to customers.

• Why: Points issued to members need to be paid for by the merchant. We first considered billing the merchants post-ante, e.g. monthly based on the points they've granted to their customers in the last 30 days, but this seems too risky: If they can't / won't pay we'd still have to pay out points to the customers (technically to the merchants where the customers redeem their points). Thus, the pragmatic idea to reduce risk by having the merchants to pre-pay for their points by topping up their balance.

• Where: Web application (with the merchant logged in)

• Nice to have: Opt-in for automatically initiated top-ups if a merchant's balance falls below a certain amount.

Invoicing

• What: After every transaction (setup, retainer, top-up,...), we need to automatically issue and send (E-Mail) an invoice to the merchant.

• Nice to have: Customer portal with all their invoices.

Other potentially relevant parameters

• Currency: Only Euro

• Country: Only Germany (so far)

• Tax: Only one tax rate

• Payment for setup & retainer: Credit Card; ideally SEPA Direct Debit (but that still causes headache due to the SEPA regulatory and risk of chargebacks still after weeks), PayPal?

• Payment for top-up: Same as above plus any other that makes sense (Klarna, Sofort, PayPal...)

Again, thank you very much for sharing your ideas and thoughts! I'd highly appreciate any input :-)

Running a subscription service with just direct calls to Stripe or similar payment gateways is possible but also needs dedicated person(s) for decent amount of development and maintenance.

Plus features like updating card details, invoice history - all these can be built. Again, more dev work and resources.

Use of subscription platform like Chargebee or Recurly is definitely a great help here.

Chargebee offered a simple pay-as-you-go transparent pricing and almost trivial signup process.

#Paymentgatewayintegration

Dear StackShare Community,

I am seeking inspiration on creating a billing & subscription stack and came across this wonderful website and community.

From what I understood so far, I need something like Stripe or Braintree to collect payments without dealing with PCI compliance or setting up merchant accounts, etc... Additionally, services like Chargebee, Recurly, Chargify, etc. are said to make life easier when dealing with recurring billing.

Stated below, I've tried to give you some context on what I want to achieve. I am very curious about your ideas and how you'd configure an optimal stack.

Project context (very high level):

• Loyalty program for local merchants (stores, restaurants,...).

• Customers support their community and merchants by shopping local.

• Merchants grant points to customers based on a customer's value spent in a store, restaurant, etc.

• Customers can redeem their points at any participating merchant.

Billing / Subscription scenarios to be considered:

(affecting merchants only)

One-time setup fee

• What: Merchant pays a setup fee by signing up for the service

• Where: Order placed on the website

Monthly retainer fee

• What: Merchant pays a monthly recurring retainer for the service.

• Where: Order placed on the website

Manually initiated payment

• What: Merchant initiates a payment to top up his virtual points wallet. E.g. pays 100 USD to top up 100000 points which then can be used by the merchant for granting points to customers.

• Why: Points issued to members need to be paid for by the merchant. We first considered billing the merchants post-ante, e.g. monthly based on the points they've granted to their customers in the last 30 days, but this seems too risky: If they can't / won't pay we'd still have to pay out points to the customers (technically to the merchants where the customers redeem their points). Thus, the pragmatic idea to reduce risk by having the merchants to pre-pay for their points by topping up their balance.

• Where: Web application (with the merchant logged in)

• Nice to have: Opt-in for automatically initiated top-ups if a merchant's balance falls below a certain amount.

Invoicing

• What: After every transaction (setup, retainer, top-up,...), we need to automatically issue and send (E-Mail) an invoice to the merchant.

• Nice to have: Customer portal with all their invoices.

Other potentially relevant parameters

• Currency: Only Euro

• Country: Only Germany (so far)

• Tax: Only one tax rate

• Payment for setup & retainer: Credit Card; ideally SEPA Direct Debit (but that still causes headache due to the SEPA regulatory and risk of chargebacks still after weeks), PayPal?

• Payment for top-up: Same as above plus any other that makes sense (Klarna, Sofort, PayPal...)

Again, thank you very much for sharing your ideas and thoughts! I'd highly appreciate any input :-)

Dear StackShare Community,

I am seeking inspiration on creating a billing & subscription stack and came across this wonderful website and community.

From what I understood so far, I need something like Stripe or Braintree to collect payments without dealing with PCI compliance or setting up merchant accounts, etc... Additionally, services like Chargebee, Recurly, Chargify, etc. are said to make life easier when dealing with recurring billing.

Stated below, I've tried to give you some context on what I want to achieve. I am very curious about your ideas and how you'd configure an optimal stack.

Project context (very high level):

• Loyalty program for local merchants (stores, restaurants,...).

• Customers support their community and merchants by shopping local.

• Merchants grant points to customers based on a customer's value spent in a store, restaurant, etc.

• Customers can redeem their points at any participating merchant.

Billing / Subscription scenarios to be considered:

(affecting merchants only)

One-time setup fee

• What: Merchant pays a setup fee by signing up for the service

• Where: Order placed on the website

Monthly retainer fee

• What: Merchant pays a monthly recurring retainer for the service.

• Where: Order placed on the website

Manually initiated payment

• What: Merchant initiates a payment to top up his virtual points wallet. E.g. pays 100 USD to top up 100000 points which then can be used by the merchant for granting points to customers.

• Why: Points issued to members need to be paid for by the merchant. We first considered billing the merchants post-ante, e.g. monthly based on the points they've granted to their customers in the last 30 days, but this seems too risky: If they can't / won't pay we'd still have to pay out points to the customers (technically to the merchants where the customers redeem their points). Thus, the pragmatic idea to reduce risk by having the merchants to pre-pay for their points by topping up their balance.

• Where: Web application (with the merchant logged in)

• Nice to have: Opt-in for automatically initiated top-ups if a merchant's balance falls below a certain amount.

Invoicing

• What: After every transaction (setup, retainer, top-up,...), we need to automatically issue and send (E-Mail) an invoice to the merchant.

• Nice to have: Customer portal with all their invoices.

Other potentially relevant parameters

• Currency: Only Euro

• Country: Only Germany (so far)

• Tax: Only one tax rate

• Payment for setup & retainer: Credit Card; ideally SEPA Direct Debit (but that still causes headache due to the SEPA regulatory and risk of chargebacks still after weeks), PayPal?

• Payment for top-up: Same as above plus any other that makes sense (Klarna, Sofort, PayPal...)

Again, thank you very much for sharing your ideas and thoughts! I'd highly appreciate any input :-)

Stripe or Paddle for payment processing for SaaS?

we used Stripe + Chargebee once and will NEVER use them again (they charge too much (300usd/month while offering way fewer integrations than Stripe)

Furthermore, Chargebee doesn't support managing disputes. We still need to go to stripe for that.

Looking forward to hearing your thoughts

To accept payments on updown.io, we first added support for Stripe which is by far the most popular payment gateway for startups and for a good reason. Their service is of awesome quality: the UI is gorgeous, the integration is easy, the documentation is great, the API is super stable and well thought. I can't recommend it enough.

We then added support for PayPal which is pretty popular for people who have money on it and don't know where to spend it (it can make it feel like you're spending less when it comes from PayPal wallet), or for people who prefer not to enter a credit card on a new website. This was pretty well received and we're currently receiving about 25% of our purchases from PayPal. The documentation and integration is much more painful than with Stripe IMO, I can't recommend them for that, but not having it is basically dodging potential sales.

Finally we more recently added support of BitPay for #Bitcoin and BitcoinCash payments, which was a pretty easy process but not worth the time in the end due to the low usage and the always changing conditions of the network: the transaction fees got huge after price raise and bitcoin because unusable for small payments, they then introduced support for BCH and a newer Bitcoin protocol for lower fees, but then you need a special wallet to pay and in the end it's too cumbersome, even for bitcoin users, to pay with it. I think unless you expect a bit number of payments using cryptocurrencies it's not worth implementing this solution, and better to accept them manually.

I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.

Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.

As of more basic stuff, we use HTML5, JavaScript (but with Vue.js too) and Webpack to handle the generation of all this.

To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .

CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.

Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.

For learning purposes, I am trying to design a dashboard that displays the total revenue from all connected webshops/marketplaces, displaying incoming orders, total orders, etc.

So I will need to get the data (using Node backend) from the Shopify and marketplace APIs, storing this in the database, and get the data from the back end.

My question is:

What kind of database should I use? Is MongoDB fine for storing this kind of data? Or should I go with a SQL database?

Hi there, I am trying to figure out if it's worth creating a Braintree account to do subscription billing in my Shopify store. The goal is to have as little custom code as possible for the store but be able to do subscription billing services, we already have a PayPal business account, but from the looks of it, we can't use PayWhirl directly with Paypal.

Stripe or Paddle for payment processing for SaaS?

we used Stripe + Chargebee once and will NEVER use them again (they charge too much (300usd/month while offering way fewer integrations than Stripe)

Furthermore, Chargebee doesn't support managing disputes. We still need to go to stripe for that.

Looking forward to hearing your thoughts

Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark