I am currently building a marketplace similar to airbnb/uber for the payment, where sellers would receive payment from buyers once the "service" is completed.
The payment solutions I am considering are Stripe and Braintree. Braintree offers Escrow while Stripe doesn't.
To make the transfer there are thus 2 solutions:
with Stripe : create an invoice object with the future date the service will happen/complete and run background jobs checking for that given date that will make the payment once it's happened.
with Braintree : use the Escrow functionality.
Is there a better solution in terms of security/scalability?
Scheduling the payment date is quite easy but since escrow is supposed to be the marketplace-way, is there really an advantage of using escrow?
I work at Braintree. If you have more questions about escrow or your Braintree integration, you can always get in touch with our support team.
The advantages of escrow don't have to do with technical security or scalability, though they make make your business less susceptible to chargebacks and other customer complaints, so they make make your business more secure and scalable.
With escrow, the money has already been charged ahead of time, so you don't have to worry about the charge being declined after the service has already been provided. You also don't have to worry about the person receiving the money taking it and failing to provide the service, since they only received the money once it's been completed. Together, these align incentives between the buyer and seller, making fraud much less likely.
Related
I develop and host a SaaS business that bills most customers directly, and that is a normal basic use-case with Stripe.
However, I also have a reseller that handles the billing relationship for those mutual customers. Since I host the SaaS service, all signups and subscription changes run through my software, and I'd like to use Stripe to track those customers, and create an invoice for each one of what the reseller owes us for them. Then I'd like to be able to charge the reseller's credit card once to pay for all those customers' invoices in one transaction. Is that possible?
Stripe Connect seems to serve the general need for handling these types of multi-party transactions. But I don't want to require the reseller to use Stripe to bill their own customers.
It seems maybe it could work if I created a single Stripe customer for the reseller, and then create a subscription for each of the reseller's customers under the reseller's customer resource. But it's not the canonical way of doing it, and I think I'd prefer a Stripe customer resource for each actual customer.
Although it might seem I could just collect payment from the reseller, and then mark all the customer invoices as paid offline but that seems it would double book revenue. I definitely don't want that!
I'm hoping someone might have a suggestion about the best way to accomplish this.
Thanks.
These types of questions are probably better suited for the Stripe support team, as they’ll be able to advise you on your business model and if there are any edge cases or unknowns you should be aware of: https://support.stripe.com/contact
I'm looking for a way to charge my customer after a request was successfully accepted.
To explain it further. I'm developing a marketplace where a private seller can sell his products to private customers. But the customer can only "request" the product and only when the seller accepts his conditions a deal is made.
Now comes the question that I have. Is it possible that the user is paying for the request but is only charged when the request is accepted?
If a request fails the charge has never been done or gets a full refund (but without the loss of transactions fees).
I've seen some couple of websites that use credit cards for that case.
If you look at credit cards as a payment method they are usually a pull-based, reusable and synchronous method of payment. This means that, after capturing the customer’s card details, you can debit arbitrary amounts from the customer’s card without them having to take any additional action and there is immediate confirmation about the success or failure of a payment.
So that is why you can charge someone after a specific period of time.
But in Germany, we don't use credit cards that often. Only pushed-based transactions like Sepa/Sofort/iDeal. Would it be possible to "delay" payments with these methods?
This should be possible. I'm not sure what payment processor you are using/want to use or what is available in Germany but I assume this would be possible with many of them. Probably some useful things to search for that might be similar to what you want would be saving payment methods for later, managing subscriptions, and tokenizing credit cards.
Stripe for example allows you to save credit cards for later under a customer record and then charge a customer later. https://stripe.com/docs/saving-cards
Braintree has recurring billing https://developers.braintreepayments.com/guides/recurring-billing/overview and a vault for storing payment methods https://articles.braintreepayments.com/control-panel/vault/overview.
Is it possible to move money between Stripe customers through ACH without having to use the merchant, myself, as an intermediary?
To facilitate payments through Stripe between users of product, you'd need to have them create Connect accounts. You can read about the process of making payouts in the stripe docs. It is currently impossible to transfer money between Customers.
It may be worth going through Stripe's list of prohibited businesses as "Money Transmitters" generally aren't allowed. Where here that is defined as transferring money without the sale of a good or service. If you want to know whether you'd run afoul of this, I recommend writing into Stripe's support.
I am working on a software that is to be used by businesses which make about $0.5mil revenue per year. I would like to incorporate into the software the option for my users to accept card payments from their clients. So far it seems I have the following options:
Manage multiple merchant accounts on behalf of my clients, however this has a few drawbacks. I would, for example, like to charge some small fee to cover the costs (about 0.1%) which I cannot accept if the payment to my user doesn't go through some stage that I can control where I can deduct the fee and send it my way. Also, about 50% of the mentioned revenue is paid for by credit or debit cards so a volume of $250,000 might not be enough to cover the fees set by the account provider.
Send everything through a merchant account that I control and then distribute the funds to the users. This, however, seems like a very small scale solution at best with the average number of payments per user per day being around 15.
The end result should be that the user enters a price in the software, this gets sent to a card reader where the user's client inserts their card and makes the payment. The amount charged includes all the fees associated. The amount paid will then be sent to some merchant account where my fee will be sent to me and the merchant fee will be deducted, the rest will be sent to my user's account. The whole point being that the user doesn't have to bother with setting up merchant account or card reader and simply gets a card reader from us which connects to the software and can immediately accept payments.
I sincerely hope I am missing something but I would appreciate any help with finding a way how to charge clients of my users and take some small fee.
So as it turns out, the best way to do this is using Stripe after all. If anyone is ever concerned, this is how I solved the problem.
Stripe is currently rolling out Managed Accounts of their Stripe Connect which can be used to effectively manage Stripe accounts for my customers. Therefore, once a user registers for my payment program, I create a managed account for them without the user knowing at all. For incoming Stripe payments I can then use the destination property as the id of the account where the money should go and specify an application fee which will be charged to my own account.
From there on the only problem to solve is that Stripe only supports online payments which can be overcome by using for example Payworks, however so far their service has been pretty terrible so this may be a weak point in the system.
I'm assisting in development of a backend for a painting service that works with many contractors across the US. We've been using Stripe, but the business has been paying the contractors using their bank's ACH service add-on which takes 3-5 days and has to be done manually.
Balanced seems like it's Stripe + next-day ACH payouts with a great API, automating everything. Is this an accurate description of the service? I'm confused why you'd ever use Stripe over Balanced in that case. This is assuming it's also a merchant account + payment gateway like Stripe if I'm reading correctly.
Still wrapping my head around how to best make this work. Thanks everyone.
Stripe:
Charge cards
ACH payouts
Recurring billing
Webhooks
OAuth merchant signup
2.9% + 30¢ per charge
Holds funds for 7 days before you can pay out
Charges in USD or CAD
Balanced:
Authorize and charge cards
ACH payouts
ACH debits
Fully API driven merchant signup
Escrow account
Recurring billing
Webhooks
2.9% + 30¢ per charge, 25¢ per ACH credit (volume pricing calculator)
Funds are available immediately for payouts (vs Stripe's 7 day rolling reserve)
Charges in USD
In a nutshell the fundamental difference is that Stripe focuses on bringing money in to your account, Balanced focuses on bringing money in, holding it until an order to fulfilled, and paying out to your merchants.
You can use Stripe to collect money and Balanced to pay out easily enough, the biggest problem you'll run into is that there will be a liquidity problem as you have to transfer funds from your Stripe to Balanced before you can pay out or create a float of 7 days.
Stripe is also great if you have sub-agents or affiliates that you want to have run the sale, but where you take a percentage of the total charge as well. We recently implemented this for a cause oriented site that supports the collection of donations for smaller and more personal causes. It is one of the more interesting features of the Stripe API. Sub accounts can be created on the fly and activated via a simple email validation creating a one-stop shop for configuring online affiliate programs.
Both are good for specific things, for example balanced will let you collect money from groups in a single pot (in their escrow), and then pay it out. Stripe is good for automated billing.
Stripe is a established company that has a polished interface and support. Balanced is a fly-by-night.
I have one site with Balanced and one with Stripe Connect, and this is the defining difference.
Balanced changed their API and completely broke all transactions.
They didn't even send out an email. Never happened with Stripe.
Balanced once "held up our site for review". Our marketplace went down with no notice or email. (And no explanation when I emailed them, just a response it was being held).
balanced.js can take 10-15 seconds to load, causing the page to hang (we implemented lazy loading just for balanced, but the page is not always ready when needed).
IRC support: Balanced has ~40 inactive users and ~10 users online ATM [in the middle of the U.S. night there are no user, and the inactive users have no AI personality]. Stripe has at least 100 active users, and I seem to be able to get an answer whenever I need to.
etc.
Balanced has one killer feature - your users can sign up and start selling immediately, they don't need to validate themselves to sell, only to receive money.
They are more likely to follow through if it's easy to get into the system. But the risks are real, and should not be ignored.
Also, if it matters, the fact that Stripe can accept payments in multiple currencies can be a killer feature as well.