I reached out to Apple Support to ask this:
Our users have to make purchases at different prices, and these prices are not fixed. We decide on these prices based on unit area and unit price. For example, let the unit price be 2 USD. Tom has 13 units of field and the amount he has to pay is 26 USD. John, on the other hand, has 38 units of field and the amount he has to pay is 76 USD. Each of our users has to pay different fees depending on the unit area in this way. In this scenario, which in-app purchase category would you recommend we choose, and what kind of in-app purchase structure would you recommend?
And they replied: "...it may be possible for you to have allow users to purchase tokens, which will then be redeemable against their own unit area."
Well, I had some more questions. My questions are:
1- Do the customers get the tokens in bundles? Can they pick an exact number?
2- Can we set these consumable tokens as expiring? For example when our users use their tokens on our services, we want them to utilize our services (that they get with the tokens) for one year. If they don't use their tokens, their tokens won't expire.
3- Can we set these tokens to provide monthly services as well?
4- Would it be better for our customers to get some tokens first (so that we don't confuse them with 2 different types of tokens: annually & monthly) and then when they pick whether they want to get our services monthly or annually, they will be asked to 'spend' their tokens at different amounts? Is that possible?
Thanks a lot!
Related
I'm selling products inside my app, that unlock items on my server. Once the purchase is through, my server needs to distribute the incoming money of the purchase to different parties.
The account that I entered on iTunes connect is a EUR account, so everything will be converted to EUR (from what I've understood).
Is there a way for me to know the exact amount I'll receive into my bank account (from the receipt for example), so I can distribute the money correctly, or does Apple simply do a currency conversion at the time of the payment?
Apple does a currency conversion plus tax calculation depending on the country it was purchased in. You can see the exact exchange rate in your payout reports in App Store Connect. More information from Apple here:
Sales and Trends estimates the USD amount of sales and proceeds based
on a rolling average of the previous month's exchange rates. Final
payments in Payments and Financial Reports are based on the exchange
rate used to convert each report currency to the currency of your bank
account.
Usually, distributing money to users before you get paid from Apple is a risky business model that's open to exploitation. Users could refund their purchases and you'd have no way of knowing until it's too late.
A safer option could be to log the unlocked items and source country the purchase was from on your server, then divide up payouts from Apple when you get them based on these figures. That way, any scammers are distributed across the marketplace as a whole and doesn't come out of your pocket.
On the getting started page for Apple Pay, it says that Apple Pay supports "partial shipments." How is this implemented in practice? I know how to get a token from a successful PKPayment. Once I get that token, how do I use it to implement multiple sub-order payments through my payment gateway?
For example, say the user validates a total $100 purchase through Apple Pay of two separate suborder shipments ($40 and $60 each) and I now have an associated token for the $100 order. Because of restrictions on some networks, we can't capture each payment until the associated item has been shipped, and they ship at different times.
Do I have the ability to authorize and capture payments of any amounts using that token?
What is the best approach to authorizing and capturing those sub orders?
Do I auth for the total ($100) and then auth for each sub total ($40, $60) at shipment and then capture for each sub total? If so, then I will be potentially authorizing more than the necessary total ($200), and that doesn't seem right. Is it valid to just skip auth for the total, auth for each sub total, and then capture the sub totals as they ship?
You can't capture an authorization more than once. For stripe you would need to save the token to a customer, and charge the customer for each shipment separately. This isn't only the best way it is the only way to do it.
Once you have a token and attach it to the customer object in stripe, you have the ability to charge it at any time & any amount up until the expiration date or if they remove the card from their apple pay account, like you would any other card regardless of the initial authorization.
The rest of your questions will vary by opinion as there are different ways of doing it, but here is how I would charge this type of order. I think this method benefits both the business and the customer, in addition to keeping stripe/apple happy. This isn't apple pay specific, I would treat most orders with these requirements the same. Also keep in mind apple pay supports it, but it is not required. You can collect all up front regardless of shipment dates.
Generate token from PKPayment for $100
Create customer(if needed) & add token to customer
Create charge against customer using that card for $100 without
capture
Within 7 days assess expected shipping dates.
Once assessment is complete immediately capture only the amount
expected to ship within a week on the initial charge. In your
example this is where I would capture $40 for the first charge. If
nothing is expected to be captured issue a complete refund.
Any shipments beyond the 7 days, create individual charges for the
shipments using the customer object, not the token. Again in your example this is when the $60 shipment goes
out charge that here.
As long as the second shipment charge doesn't happen to go out earlier than the 7 days this would prevent any authorizations overlapping resulting in holds of more than the initial amount at any given moment. I would treat almost any transaction like this apple pay or not.
I am developing online shopping App for iPhone. For financial transaction, I have used PayPal SDK and also created sandbox accounts for both buyer and receiver having US based account. I also had a test with US currency (USD) and credit/debit happens perfectly on both the accounts.
But, now I need to give support of non-USD currency, i.e INR as my App will be distributed over India. The only bottleneck is, INR is not in Paypal’s currency support list unfortunately. What should I do? Suppose, buyer buys product worth 100.00 INR and buyer have US based account having $ 500.00 balance. Now at end of transaction, based on exchange rate of these two currencies, amount should be deducted from buyer's account.
How can I manage this kind of multi-currency transaction ?
#Pratik It sounds like your app will need to do its own currency conversion from INR to USD, and then perform the PayPal transaction in USD.
There are many online currency converters, including some that return their results as JSON.
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 You may not enable end-users to purchase Currency of any kind through the In App
Purchase API, including but not limited to any Currency for exchange,
gifting, redemption, transfer, trading or use in purchasing or
obtaining anything within or outside of Your Application. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,
We are prepping for the release of a large web application that has been in development for the past year. We are about to start the process of integrating ActiveMerchant to handle recurring subscription fees for the service.
I am looking for any advice regarding best practices considering our requirements (listed below) and any additional heads-up for common pitfalls or specific issues I should be giving special consideration. The payment gateway we will be using is PaymentExpress as it's one of the few supported gateways that has recurring billing and doesn't have any special conditions for companies operating outside of the USA. The business behind this application is based out of the UK.
Users of the application create an account with a sub-domain where they can access and customise the application and their data. Below are some of the requirements/features that might have an effect on how billing works:
All users get a 30 day trial
There are different plans, including a free one
Higher priced plans have larger limits on the amount of data (e.g. users, projects, etc) they can have in their account
Billing period will be monthly, beginning after trial
There will be discounts/coupon codes to get a percentage off the normal price for a year on plans, etc.
Plan pricing will change as features are added
Specific hurdles I can foresee will be things including the following:
How to handle downgrading when they violate the plan limits for lower level plans.
Behaviour when credit cards expire or payments don't go through (a read-only mode enforced, perhaps)
When plan pricing changes, we want to honour previous prices for existing users for a time period (such as 6 months), then start charging higher rates. If the plan price decreases, it will take effect immediately.
Other advice that would be helpful would be anything regarding flow of the application. How should billing forms be presented to the user? When should credit card information be required? How should invoices be sent, stored, and accessible?
I should disclose that we plan to base a lot of the code base off SaaSy. SaaSy is designed to be used as a separate Rails app that handles all the signup and account management side of things. However, this doesn't work for us since we never planned for this from the beginning and it would be a tedious process to adapt our application to work like that. Consequently, we'll be pulling code and ideas from SaaSy and merging them into our app, a considerably less tedious task.
One thing I wanted to add: keep in mind you don't need to use the recurring billing feature that is built into the gateway. In general these systems are legacy and very difficult to deal with, we get spoiled in the rails world.
You get a lot more flexibility just using them for one purpose (to bill a credit card, and perhaps also store credit cards for PCI compliance). Then roll your own recurring billing in your rails app with a cron job, a date field for when they are paid through, and amount each person is paying (in case they used a coupon) etc.
One small example: sometimes people will cancel a monthly subscription in the middle of the month. They want to make sure they don't forget to cancel before the next payment. Most gateway recurring billing that I've seen will instantly terminate the account (or send you a message indicating this). In reality, the user has paid through the end of the month and should be given 2 more weeks of access. You can do this if you have rolled your own recurring billing in rails, but not if you are using the gateway recurring billing. Just a small example.
RailsKits has a Software as a Service kit that should do what you need. It has built-in support for free trials, upgrading, downgrading, plan limits, etc., and it supports PaymentExpress (and some others).
I've researched it a bit for a project I'm doing, but I haven't purchased it yet so I can't vouch for it. However, I have seen a few blog posts praising this kit.
While the RailsKit is relatively inexpensive when compared what it would cost you to implement all of its features yourself, there are a couple open source versions out there that aim to accomplish the same thing. The one I remember off the top of my head is called Freemium.
EDIT: I forgot to mention that Ryan Bates said in his most recent Railscast that his next episode or two will deal with recurring billing, so keep an eye out for that. He usually does one episode per week, and the five he's done since December 22 all cover handling payments of different types.
Peepcode has a PDF for sale(70 pages) that details various aspects of payment processing and industry practices for this. It may be worth checking out:
http://peepcode.com/products/activemerchant-pdf
I'm also in the middle of setting up a subscription based website and these are our current requirements. They may help you regarding best practice:
Users will be able to choose one of
the subscription plans.
Users will be required to enter their
credit card details to sign up to
their chosen plan.
All major credit and debit cards must
be accepted including Maestro and
American Express.
Each plan will have a 30-day free
trial so users' credit cards should
only be charged after the 30-day
period expires. However, the validity
of credits cards should be checked at
the time of sign up.
Users will be emailed a few days
before their credit card is charged
to notify them that they will be
charged soon unless they cancel their
account. If they cancel their account
within their 30 day free trial, their
credit card should not be charged.
After any free trial period, users
will be charged in advance for their
use of the system - ie they will
pre-pay.
Users will be charged automatically
every month for their chosen plan.
Each month, users will be sent an
email a few days in advance to notify
them that they will be charged. Once
payment has been made, users will be
emailed an invoice showing that their
payment has been received.
Users will be able to upgrade or
downgrade their accounts at any time.
When users upgrade/downgrade, their
next subscription charge will be at
the new rate. Users will only be able
to downgrade their accounts to a plan
that can handle their data. For
example, if they currently have 10
active projects they can't downgrade
to the Basic plan because the Basic
plan only allows 5 projects. They
will have to delete or archive 5
projects before you they can
downgrade to Basic.
Users will be able to log in to their
account and change or update their
credit card details.
Users will be able to cancel their
account at any time. There will be no
further subscription charges after a
user has canceled their account.
However, users will not be refunded
for part of the month they have
already paid for.
All parts of the payment system must
be 100% PCI DSS compliant; including
any 3rd party systems.
The payment system must support
automated notification and retry of
failed subscription renewals.
The payment system must support
discount vouchers with expiry dates.
Credit card details must not be
processed by or stored on our servers
they should always be processed/stored by our 3rd party
payment processing partner. We do not
want responsibility for securing
these details and complying with
legal rules and regulations.
Users will be able to log into their
accounts and see a full billing
history including dates and amounts
paid. We will also need to be
able to log in to a system to see
customer payment plans and payment
history. This will be essential for
customer service.
We've also been looking at http://chargify.com/ which looks like it could save a lot of coding time.