I have some queries on Microsoft Translator API
1.If i use trial period before characters limit will be over am i going to get any emails from the configured email in datamarket.azure.com. I have seen that notifications will appear in our account when our subscription balance is 15% of our monthly limit and when our balance is completely finished, but i think these notifications will display in our www.datamarket.azure.com account. It's not good to check our account regular basis.So is there any other approach which is maintaining by Microsoft?
2.is there any specific limited characters or transactions per day for paid service also?
I referred this link but i didn't get much details
https://datamarket.azure.com/help-overview-purchasing-subcribing-data-apps#x_taxes
Please provide me the answers for the above queries.
Microsoft translator Support has sent a response for the above queries as follows
1.At this time the notification for low balances only appear in your Windows Azure Marketplace account. The email notification for low balances is a priority feature that we expect to be included in a future release of Marketplace. If you subscribe to a paid monthly subscription, a new feature for paid Translator API subscribers called ‘Auto-Refill’ was added last week and you may find this to be useful depending on your usage scenario.
If you enable this feature for your paid Translator API subscription, you allow Marketplace to automatically refill your subscription if your remaining balance reaches 10% or less of your monthly subscription limit. More information on Auto-Refill can be found here.
2.You are currently able to translate a maximum of 10000 characters per request, but we recommend keeping each request between 2000 and 5000 characters to optimize response times.
Related
I wanna use CloudKit for a new App of mine which will be free (0$). That's why it would be bad if my app would reach the free tier limit of Apples Cloud Kit plans and to occasion costs.
I read some posts, the official Apple developer documentation, etc. I did not find a way how to prevent it by rule or by an code-sided check to use more quota as the free tier would provided.
Is such a thing possible?
To my knowledge, you will not be charged automatically if you exceed the free CloudKit transfer/storage limits. Instead, the CloudKit response will be an error. For example, if too many clients send requests at the same time, some of them will receive a CKErrorLimitExceeded. If you look at the CloudKit Error Codes, you will find similar codes for exceeded storage quota.
I have an iOS app with different auto-renewal subscription possibilities, and I want to offer it's user the chance to earn a free month when they invite friends to the app.
I know how to handle the scenario where I'd give a free month to a user that's not already subscribed, but I'm wondering how to handle a user that's in the middle of a year-long paid subscription and should receive a free month..
EDIT
Make sure to read budiDino reply below, it seems this is now possible (Full disclosure, I haven't tried it myself but I did glance over the references linked).
OLD ANSWER
Ok, after some digging and asking around on Apple's forums I can confirm it's not possible.
The only way to achieve this is to give users a free month outside of Apple's subscription process...meaning users should turn off auto renewal to enjoy those free months.
Whether this is good or bad for your app depends, but it required that the user manually turns off auto-renewal while using the earner out of charge time, and then turn it on to get back into the normal auto-renewal flow handled by Apple.
You can maintain a value like additionalMonths on your server side.
So once his subscription period gets over, you can check for the value of additionalMonths and accordingly provide him subscription for those number of months.
1. Promotional Offers
This option allows you to add a free or discounted price for a period that you specify and it will be executed before the next payment cycle. You can use this feature starting with iOS 12.2.
Apple Documentation:
You can provide lapsed or current subscribers a limited-time offer of a discounted or free period of service for auto-renewable subscriptions on macOS, iOS, and tvOS.
Some useful links:
Implementing Promotional Offers in Your App
Set up promotional offers for auto-renewable subscriptions
Subscription Offers Best Practices video - WWDC 2019.
2. Offer Codes
Apple Documentation:
Offer codes can help you acquire, retain, and win back subscribers by providing a subscription at a discount or for free for a limited time.
Read more
3. "Extend a Subscription Renewal Date" endpoint:
Potentially simpler alternative that is not really suggested to use for this use-case. It has certain limitations though:
you can move the renewal date for a customer’s subscription up to 90 days into the future for each extension
you can extend the renewal date twice within a year (365 days) per customer
The following types of subscriptions aren’t eligible for renewal date extensions:
Subscriptions in a free offer period
Inactive subscriptions in a billing retry state
Subscriptions in a grace period state, with an expiration date in the past
Subscriptions that have already received two renewal date extensions within the last 365 days
Read more
I am building a webapp which requires users to regularly top up their account. To allow for this I am exploring the google wallet inapp payments api and have got this working fine. However, I would like users to be given the option to auto-top up when their account balance becomes low. I have looked at the subscription documentation but cannot see whether this is possible or not - it seems you can only have a subscription which draws money at regular intervals.
Is there a way to have a user pre-authorise this kind of transaction, and if so could you please point me to any documentation that would allow for this?
I don't believe so. The subscription feature is probably your best bet and should (unless I'm missing something) get you to the "same place".
A "pre-authorization" somewhat says, you'll come back at some later time to charge (aka "capture") the pre-auth. There is no API command that does that (capture/charge) in Wallet for Digital Goods. The process is immediate...
There (is) used to be one in the Google Checkout API where you are given 7 calendar days to charge a pre-auth. However, this product will be retired in November.
On WhitePages.com they have a mechanism in place that facilitates payment by entering your telephone number. After you enter your number, you get an SMS that instructs you to enter "GO" in order to complete the transaction. Following that reply with the purchase you've made, you get another message suggesting that for a certain monthly fee you can use the service in an unlimited fashion. I had not seen anything with quite those dynamics before and I'm curious of what service(s) one would use to construct a payment system like this for a Ruby on Rails app?
I am particularly interested in a platform that allows this kind of payment from as many countries as possible as I currently use Twilio for SMS messaging on another app.
Without knowing the full details of what WhitePages.com offer it sounds like they're using Premium SMS as a method of collecting payment from a mobile.
After you've entered your telephone number, they'll send you a text with the originator set to a premium shortcode (rather than from a long number). The reply you send back to the premium shortcode is deemed your acceptance to be charged more than your standard network SMS rate. The amount of the charge can vary but should be made obvious to subscribers before they are charged. This Mobile-Originated reply text (MO) is what causes the charge to be taken from your mobile telephone number bill.
Premium subscription services can then subsequently generate further charges whilst the user is still subscribed by sending messages from the premium shortcode. The act of receiving these messages causes a charge to be applied to your mobile telephone bill. These are deemed Mobile-Terminated texts (MT).
Premium SMS is not a simple solution for collecting payment for a number of reasons.
You often only receive a small percentage of what the user is being charged on their bill as the mobile networks keep a cut for offering the service.
As this relies on premium shortcodes you may have to accept you'll have different numbers for each country you want to operate in as you'll have to organise premium shortcodes in each country.
There's different regulations regarding Premium services that you need to be aware of in each country. For example, users need to be able to unsubscribe / opt-out of premium services once subscribed so premium services often have to comply with receiving 'STOP' and 'STOP ALL' messages from users.
As far as I know, Twilio doesn't support premium shortcodes at this time. There are other SMS Gateways which do support premium SMS but you won't get a single solution to fit any country you wish to operate in. Interacting with this kind of system is usually no more complex than sending and receiving normal SMS so the task of creating this with a Ruby on Rails app should be no more complex.
Normal SMS is pretty much globally universal. Premium SMS is an additional country specific feature.
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.