I am working on a project where I need to capture one time payments from an account. For a bit of background: The account has many users, where users are part of teams as team_members. I have another model we can call projects where teams are affixed to the project. It is on these individual projects that I would like to have a checkout button. The price for this one time payment should be calculated based on the number of individuals in a team, that are part of this project.
My issue is that I am not 100% sure how to achieve this for one time payments in stripe. Should I set this up alike that if I were to sell an individual item? Product (with name, description and price) and an Order to affix to the user?
I've built subscriptions plans in Stripe before, but have never really used one time payments. Any guidance on setup here would be really great.
Small Edit:
When a project is created, a team is selected. That team size is known to the project.
If I have 3 tiers for pricing:
1-5 people in a team is $x
6-20 people in a team is $y
21+ people in a team is $z
How would I go about invoking the correct tier based on the team size for the project?
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
You should calculate the amount you want to charge in your own business logic. Once you've got that number, there are several ways you can collect one-time payments with Stripe.
If you want to offer the most flexibility for supported payment methods with the lowest amount of integration effort, Checkout would be a great option. You would supply the amount and a description with the line items while creating the checkout session.
If you want to keep users on your application while paying, following the web payment example is what you'll want to do. You would provide the amount when creating the PaymentIntent.
Related
Before moving too far into a project, I'm looking to know if with my twilio account I can have two different numbers being billed separately, or if it's only able to be on one invoice. I work for a small organization in which I do bulk text messaging to make sure everyone gets updates, invites, etc. The leaders ask me for the monthly invoice and repay me for the cost. Now, I don't want them to unknowingly be paying for my private project. If I was to purchase a second number, could it be billed separately so that invoices could be separately?
Yes, but only if that is under a completely different Twilio Project.
So, I have a web application that is built using Ruby on Rails and VueJS where people can order food and I'm currently using Stripe as the payment gateway. Currently, users can select which meal they like and select how many guests so it multiplies the cost by number of guests then proceed to pay for it via CC on our platform. We're using Stripe "managed accounts".
What I would like to accomplish though is, if a user selects 2 guests then they have the option to pay for it themselves or pay for their half and then have the other guest pay for their half. Essentially we'd like the ability to divide the payments amongst the guests as an option.
How can we accomplish this using Stripe?
Stripe's API does not have any facilities for this specific scenario: a charge with Stripe has a single payment source.
If you want to split the bill between multiple customers, it's up to you to create as many charges as needed, with the right amounts.
If you do this, keep in mind that it's possible that some of the charges will succeed and others will fail. You might want to use the auth & capture flow to first create authorizations, and only capture them if all the authorizations succeeded.
We have two .NET apps used to import customers and transactions into our db.
One is "client" app running on QB user's side another one is a small web service to interact with web connector.
We save all custmers and their "base class" transactions / changes in our DB and display on a web site. Users can see their transaction information there. Problem is that customer's balance does not always get equal to Sum(Amount) for their transactions. We already know that a customer can have a job (sub level customer) and count those transactions too. Still it appeared that a customer can get payment discounts and we needed to count that too.
What is a reliable way of counting customer's balance which always coinside with to their balance ?
I read a post about using Balance Detail Reports but I'd like not use it.
Thanks,
Vlad
It's hard to give a exact answer as there's a lot of little pieces that you may be missing, we don't know how you are calculating your totals so it's just guess work here. Here's a list of the transactions that I know of that effect a customer's balance, along with some things to look for.
Invoices can have a subtotal and sales tax which should both increase the balance.
Receive Payments can have discounts which should also reduce the balance along with the payment amount.
Journal Entries against Accounts Receivable for the Customer will either increase or decrease the balance depending on if it's a debit or credit to the AR account.
Credit Memos should reduce the balance.
Keep in mind there may be more than one Accounts Receivable account, so you need to make sure you don't filter for all A/R accounts on Journal Entries.
Your best bet to figure out what you are missing is to find a customer who has a different balance than what you calculated and review your detailed transactions vs. the detailed transaction for the customer in QuickBooks.
I know it's possible to sit between a payer and payee using PayPal by just storing payee's PayPal account information.
Is it possible to take a percentage of the that transaction and pay it to a different PayPal account. Basically acting as a service fee for using our website?
If it helps, I would probably be using Active Merchant for rails.
What you are looking for is called "Chained Payments". You can take a commission from a payment, and the remainder can be split with one or more payees. The original payer only sees you. Chained payments are one of the several types of workflows you can get through the "Adaptive Payments" API.
More info on:
https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
and pages 18 and 19 of the following manual on Adaotive Payments manual at cms.paypal.com/cms_content/US/en_US/files/developer/PP_AdaptivePayments.pdf
I was looking into this very same scenario, and I believe I've found that it is supported via PayPal's Website Payment Pro API. It appears as though there are several available use cases, such as:
Taking a cut, as you described
Dividing up a single customer payment among multiple payees (so if you have a shopping car where you resell items from several different providers, you can divide the payments up based on who provided each item)
Take a look at the document here and see if it fits your needs. I'd be very curious to hear how your integration goes, since I'm looking at something very similar for my forthcoming site.
https://www.x.com/docs/DOC-1328
EDIT: You should also take a look at the Adaptive Payments API. That was the other service I found that may fit this use case...
https://www.x.com/community/ppx/adaptive_payments
You can automatically charge transaction fees between the payer and payee if you use the Amazon Payment Service. It explicitly supports your business model.
We want to add billing capabilities to our rails-driven web application. I've come across two plugins that do that - Service Merchant (which is free) and SaaS Rails kit (which costs money).
Does someone have some experience with these plugins (or others with the same functionality)? which one would you recommend?
Thanks!
I looked at both of them and unfortunately neither met my needs.
You say that you want to "add billing capabilities" -- but how complex are your bills?
Subscriptions?
Multiple subscriptions possible per customer at same time?
Any variable monthly costs? (eg the customer pays every month, but the amount they pay varies depending on something.)
Any additional items that aren't monthly? (eg setup charge, consulting, etc)
Billing subscriptions in advance? (like the phone company bills monthly service.) Or billing in arrears? (Customer uses service, then you bill them.)
There are very expensive companies you can outsource this stuff to (~ $25K - $50K and up for initial setup). Eg www.zuora.com
Or you can roll your own and charge the credit card using ActiveMerchant. Be sure to store the credit card info at your card processor (eg Authorize.Net Customer Information Manager).
If you're venture backed, then consult your VC for ideas. It may be worthwhile for you to outsource the whole thing.
If you're a lean startup, use one of the low-end guys if you have a simple subscription model. If your billing is more complex than that, the right answer may be to roll your own.
Low end subscription billers: Chargify, recurly, Google for "subscription billing"
No experience with those plugins, but I highly recommend using chargify to do recurring subscription billing. You'll use their rest-based API to create 'subscriptions' and it handles all of the charges, emails, and canceling subscriptions for you.
You'll pay chargify per user on a monthly basis (but it's cheap), and you pay the credit card processor, but there's no setup fees to chargify to get started.
http://chargify.com/