In our app implemented multiple plans, every plan provides more o less functionality for our clients, depending on that the price of the different plan is different.
Our plans implementation based on the RecurringApplicationCharge Shopify feature
We know that Shop owners are charged immediately upon accepting an application charge. Hence the question what happening:
if shop owner change plan from a less expensive charge to a more expensive charge
if shop owner downgrade plan by moving from a more expensive charge to a less expensive charge
?
I found billing FAQ for the shop owners, where written:
If you upgrade or downgrade your subscription with an app, then the app will prompt you to agree to a new recurring app charge. This is because Shopify allows each app only one recurring app charge to be enabled at a time. The existing recurring application charge will be canceled and replaced by the new charge.
When you upgrade your plan by moving from a less expensive charge to a more expensive charge, the charge is prorated based on the difference in price and the number of days remaining in the billing cycle. For example, if you begin a 30-day billing cycle on a $5.00 plan, and then upgrade to a $15.00 plan on day 15 of the billing cycle, you'd be charged $5.00 + ($15.00 - $5.00) * (15/30) = $10.00 USD.
do these rules work for the RecurringApplicationCharge? Or here talking about the GraphQL subscription model?
If shop owner change plan from a less expensive charge to a more expensive charge
As mentioned in the example provided by Shopify a new recurring charge would be created and the merchant needs those charges to be accepted for the charge to happen. You need to manage your code logic so as to if a merchant chooses to upgrade a new charge will be made and the pro rated amount will be charged to the merchant.
If shop owner downgrade plan by moving from a more expensive charge to a less expensive charge
There won't be any refund in this case. You would however need to create a new Recurring charge which the merchant will be charged in the upcoming billing cycle. The merchant needs to accept the new recurring charge.
Do these rules work for the RecurringApplicationCharge? Or here talking about the GraphQL subscription model?
Both do the same thing
Related
New here and i hope i am in the right place to ask my question. We are having problem with submitting our app to Shopify App Store.
We have an app where people can create their own designs on our physical products and sell. So we can produce their products and dropship to their customers. There are many apps to that.
Problem is they forcing us to use Billing API for our product charges. They take 20% of commission which our margin is not that much. We are wholesaler and we our margin is super low. We use (well we were planing to use) Stripe for products charges, which is 2.9 % commission.
And Shopify Apps Team member is keep asking me my margin, and says: "We are requiring that all apps use the billing API, but I might be able to make an exception since it seems like your business model isn't compatible. If an exception is made, you will be required to sign a revenue share agreement based on your margins"
All other App (in our business line)they charge their customers with 3th party payment processors and i have spoken with some of them they say they never heard about it and they don't share any revenue (apart from membership fees) with Shopify.
Any idea about this?
Thank you so much for you help.
Shopify is charging 20% of the cost of the app not 20% of the cost of your finished products. I don't know if your app can be free and still in the app store but from what you have written free would work since you will actually make your money on the goods. Just bill normally for the orders you receive
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
I have an App in the Shopify App store that uses a recurring application charge. No problems there.
Sometimes, one of my users will make a suggestion to improve the app. I would like to reward them with a free month of using the app without being charged.
Based on the Shopify API, The only thing I can think of is to cancel the current recurring application charge, create a new charge for $0, then a month later cancel that charge and create new one for the original price. This is far from ideal. I believe that the user would need to accept every new charge that is created.
Is there a better way? Any suggestions?
Agreed that that sounds pretty far from ideal.
If you create a new recurring app charge with a 30 day trial period, Shopify will change the customer over to this new charge while respecting the trial period. The customer will still see a prorated charge for the partial payment cycle before you “upgraded their plan” after the trial is up, but this will effectively do what you want.
As of 2017 there is now an API for granting credits to merchants using your app:
https://www.shopify.com/partners/blog/using-the-shopify-api-to-credit-merchants-for-app-charges
https://help.shopify.com/api/reference/applicationcredit
I have a bit of a conundrum with my Rails application. It looks like the model we are going to use for billing is per-use as opposed to a subscription basis (at least initially). While we've already implemented Recurly's Transparent Post API (great product), it's likely overkill.
We could simply establish a free plan with no monthly charge and then initiate one time transactions. This satisfies the level of PCI Compliance we are looking for and also allows returning customers to have their credit card information stored by a third party.
To further complicate things, there may be a requirement in the future for subscription based plans in addition to the per-use billing. I am looking for some advice about whether to stay with the recurring billing platform or whether I might want to simply use ActiveMerchant, not store credit cards and deal with the change in PCI Compliance (onus is on us and not a third party). Also wondering if there is another tool that handles one-time repeatable transactions without having a subscription plan?
You could use ActiveMerchant with Authorize.net CIM or Braintree to store the card info for you (for the PCI compliance) and run transactions for whatever amount at whatever time based on the token you would get back from either of those. That wouldn't preclude from adding on the recurring billing later -- you would just start charging against those stored tokens on an automated basis.
The SaaS Rails Kit (which I wrote) takes this approach for doing both the recurring billing and one-off transactions.
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1