Alternatives to Xoom

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.

Google Analytics is a great tool to analyze your traffic. To debug our software and ask questions, we love to use Postman and Stack Overflow. Google Drive helps our team to share documents. We're able to build our great products through the APIs by Google Maps, CloudFlare, Stripe, PayPal, Twilio, Let's Encrypt, and TensorFlow.

Using Screenhero via Slack was getting to be pretty horrible. Video and sound quality was often times pretty bad and worst of all the service just wasn't reliable. We all had high hopes when the acquisition went through but ultimately, the product just didn't live up to expectations. We ended up trying Zoom after I had heard about it from some friends at other companies. We noticed the video/sound quality was better, and more importantly it was super reliable. The Slack integration was awesome (just type /zoom and it starts a call)

You can schedule recurring calls which is helpful. There's a G Suite (Google Calendar) integration which lets you add a Zoom call (w/dial in info + link to web/mobile) with the click of a button.

Meeting recordings (video and audio) are really nice, you get recordings stored in the cloud on the higher tier plans. One of our engineers, Jerome, actually built a cool little Slack integration using the Slack API and Zoom API so that every time a recording is processed, a link gets posted to the "event-recordings" channel. The iOS app is great too!

#WebAndVideoConferencing #videochat

Server side

We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.

• Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.

• Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.

• Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.

Client side

• UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.

• State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.

• Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.

Cache

• Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.

Database

• Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.

Infrastructure

• Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.

Other Tools

• Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.

• Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.

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.

Google Analytics is a great tool to analyze your traffic. To debug our software and ask questions, we love to use Postman and Stack Overflow. Google Drive helps our team to share documents. We're able to build our great products through the APIs by Google Maps, CloudFlare, Stripe, PayPal, Twilio, Let's Encrypt, and TensorFlow.

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 :-)

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.

I'm planning to build a cryptocurrency wallet app, in the end, I'd like to also add NFT's to the app and be able to access their details (smart contract, token id, blockchain) but I haven't figured out the process on how to do this so far.

Would it be possible to do these using SDKs like Blockchain /Coinbase or should I start from scratch? If so, which kind of architecture should I use? I am hesitant to use ETH as the starting point as the transaction fees are too high for testing.

Stripe Stripe Billing Vue.js

When I started building a SaaS from scratch, I adopted the Stripe Billing product for managing plans and subscriptions. At that moment (roughly a year ago) I did not fully realise that this was a new addition to the Stripe product line.

One year down the road, I can write this decision and support it with technical details on how I implemented Stripe Billing and integrated it with the Checkly backend.

Key takeaways are:

• Keep coupling minimal. I hardcode our pricing and plans into the pricing page.

• Choose good ID's and a good structure to segment product and pricing. This enables grandfathering customers and adding ad hoc new products.

• Use one or two webhooks to keep things in sync. We use just one webhook.

See all details with code examples in the linked blog post.

We're looking for a payment gateway with a robust and dependable API. We will be accepting recurring payments for premium plans on our website, preferably in as many regions as possible.

While looking for Stripe alternatives, we found Adyen, which seemed like a viable option - we would love to hear your thoughts!

I appreciate your time reading this message and hope to hear back from you about your experiences with payment gateways!

I am developing an MVP; our app will accept money transfers for cross-border payment. Any advice on using Adyen for cross-border payments over Stripe? Please advise