Hello I have a monthly subscription on my app using Braintree which is working ok. I would like some advice on best practices for the event where payments aren't made on time for whatever reason.
I currently have a User model with subscribed:boolean subscribeddate:date and subscribedend:date.
When a user completes payment through braintree, the attributes get updated to subscribed:true subscribeddate:Date.today and subscribedend:Sometime_way_in_the_future .
When a user cancels a subscription, the attributes get updated too, subscribed:false and subscribedend:(a braintree attribute, billing_due_date)
This way I can filter things in my app according to dates and subscription status. The only problem I can see with this is if Braintree tries to charge an account one month but fails. Braintree has an attribute for this (.days_past_due), but my app has no way of knowing whether this has occurred or not.
What are the best practices for this? Should I do a scheduled task each day to check if every single user has a value for the .days_past_due attribute on the Braintree server? Would this not be incredibly slow if I have a lot of users?
I may be going about this all wrong and I'd just like a bit of advice on the matter,
Thanks.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support#braintreepayments.com.
Your best bet is going to be to implement Braintree's recurring billing webhooks. Webhooks send you a notification via HTTP POST whenever an event occurs that may not have been directly triggered by an API call—such as a customer getting charged via their subscription, a subscription getting canceled, or a subscription going past due. This will allow you to directly respond to subscription events, without having to perform daily checks to see if any changes have occurred.
To use webhooks, you need to choose which events you want to receive webhooks for, designate an endpoint on your server where we'll send the notifications, and set up that endpoint with code to parse the webhook notification into a useable form. For details, see this guide with instructions.
Related
I have successfully implemented subscription validation for Google Play, but I am struggling to understand the validation flow for iOS auto-renewable subscriptions and would like to ask for your help. Here is how high-level logic for Google Play:
New subscription validation
User purchases subscription in the app.
A SubscriptionRequest is created in my Firestore database, which includes the UserID and the token of the transaction.
A cloud function picks up that SubscriptionRequest and queries the relevant Google API using the token to get the subscription details. This is done using the googleapis Node.js libary.
The latest subscription details are saved in Firestore as a Subscription, including the token (as linkedPurchaseToken) and the UserID.
The expiry date of the subscription is evaluated and, if it is not expired, the User in Firebase is updated and the flag hasActiveSubscription is set accordingly (including Google Play identifier of the subscription, e.g. monthly_sub, or annual_sub, and the platform, in this case android).
Google Play Developer notifications
Notification is received via a Pub/Sub cloud function.
The corresponding subscription details will be fetched using the relevant Google API and the token from the notification.
If no Subscription with that token (as linkedPurchaseToken) exists in the database, we'll try to get find the existing Subscription in our database using the linkedPurchaseToken from the subscription details that were fetched in (2).
If still no Subscription can be found in the database, that obviously means that it's a new subscription, which will be handled exclusively via the New subscription validation process described above. The reason for this is that I am otherwise unable to link my UserID and the subscription.
If a Subscription is found, it is updated with the latest details.
The expiry date of the subscription is evaluated and, if it is not expired, the User in Firebase is updated and the flag hasActiveSubscription is set accordingly. [...]
This has been working exceptionally well and robust for quite some time.
As far as I can see the developerPayload, which could be used to pass on, e.g. the UserID, to determine who the subscription belongs to, is deprecated. (Source)
Do you think there is an easier way of doing this, possibly
only using Google Play Developer notifications?
I am receiving a notification at every step a subscription changes and I am simply updating my Subscription and hasActiveSubscription flag based on the expiry date. This is working well because I receive a notification at the moment the subscription expires (notification type SUBSCRIPTION_EXPIRED) and at any point the subscription gets extended, for example. (Source)
Is there anything missing in that validation logic or any potential risk?
These two questions so far are only to ensure I am not missing something essential. Again, from my experience this is working quite well.
All that is left for my app (based on Flutter, by the way) to be released on iOS is to implement the validation logic for iOS.
One thing that has made the google validation logic rather easy, is that there is the googleapis library, which essentially is giving me the model classes for all responses, such as the notifications or the subscription details. I have been unable to find something similar for Apple yet and I am not sure there is.
Is there any (official) library that is providing me with similar features as googleapis for Node.js?
For new subscriptions I am currently querying the verifyReceipt endpoint, which seems to be working well. However, Apple does not seem to say anywhere which fields need to be validated exactly, in order to provide users with access within the app. I am following the same logic, meaning: If I do receive a valid receipt from the endpoint and it is not expired, I grant access.
Is that logic sufficient for new subscriptions or am I missing something?
For Google so far I simply stored the subscription details that I received via querying the api, including the UserID and token. This is done mainly for laziness and because the document structure received is rather simple. The Apple responses are much more complex, so I am quite unsure about what to store (and poorly documented, if you ask me), so I am wondering:
Which details do I actually need, for both Google and Apple, especially if I rely on notifications for updating the subscription?
Regarding updates to the subscriptions, I am wondering how to work with server-to-server notifications from Apple.
When exactly are they being send and can I implement the same logic as described above for Android?
As I can't seem to find a good documentation or tutorial for this part:
Do you possibly know any good tutorials for these notifications?
Thank you very much for your support,
Matthias
It has been a while since i asked these questions and while technically the questions have not been answered, I would still like to share my solution with everyone.
The solution I have gone for is simply implementing RevenueCat, who focus on managing in app subscriptions for you, so that there is no need to worry about all those questions anymore.
I have followed some tutorials on implementing In-App purchases and subscriptions for iOS (especially Ray Wenderlich) but I have doubts on how to integrate our iOS app with our website so that if someone subscribes to the app they can access the content on the web as well.
Our website and app offer access to videos. All subscribers have access to all videos. Our web works with PHP and MySQL. When someone subscribes on the web, a record for their account is created in our MySQL database and they are flagged as subscribers so that they can access the content.
We want to implement in-app subscription in our app, but we need for a record to be created in our database when the subscription takes place.
The question is, should we do this upon receipt validation (we'll be doing this in PHP)? Also, is there a way to know when a user unsubscribes through iOS so that the database can be updated accordingly?
Our closest example of how we would like it to work is Gaia.
Should we do this upon receipt validation?
Yes, you should wait until you validate the receipt to mark the subscription as active for the user.
Is there a way to know when a user unsubscribes through iOS so that
the database can be updated accordingly?
The correct way to implement this is to store the entire IAP receipt on your server and periodically refresh it with Apple to get the current subscription status. Just because somebody started a subscription doesn't mean it will still be active the next time you check it (e.g. they may have turned off auto-renew or been issued a refund).
This blog posts explains some of the nuances in further detail: iOS Subscriptions Are Hard
Is there a way to know when a user unsubscribes through iOS so that
the database can be updated accordingly?
Use status update notification.
A statusUpdateNotification is a server-to-server notification service
for auto-renewable subscriptions. A notification specifies the status
of a subscription at the time the notification is sent.
As status update notification is not a reliable service, Apple recommend to use this in combination of other method such as polling the verifyreceipt end point. creating a scheduler in server will be best option along with notification.
In a ruby on rails app I want the ability for a person to donate to my paypal. However, I want to get a callback to know how much they donated. Is this possible with the default paypal 'buy' or 'donate' button, or will I have to use some sort of paypal api. Hopefully, there is some option besides the api.
Any info at all would be much appreciated.
Take a look at Instant Payment Notification (IPN). When IPN is configured PayPal will POST transaction data to a listener script you have sitting on your server. It'll handle payments, refunds, disputes, or pretty much any transaction that hits your PayPal account so you can automate things based on specific events in real-time.
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.
I want to Integrate Authorized.Net ARB and AIM together using rails.
Actually, I want Instant payment when user signs up today and I want the subscription to start today. for this i want to charge their first payment via the AIM API. and if AIM tranaction get succeed then only i will create ARB.I write code for both my ARB works perfect but when i write code for the AIM it gives error This transaction has been declined but when i create an ARB with same card it works perfectly.I really don't know how to go for this.
Also I want to know when subscription is declined when processing a future scheduled payment is Authorize.Net cancelled that Subscription or try again on next day?if it try next day again how many times it will try? Can I check or write a code using SILENT POST that after 5 times it's subscription should get cancelled.
ARB performs no validation of a credit card when a subscription is created (other then validating the card has a valid card number format, properly formatted expiration date, etc and won't expire before the first payment is scheduled for). Therefore you have to use AIM to validate the card first, either by running a transaction or performing an AUTH_ONLY, and then if it is successful establish the subscription with ARB. Basically once you get that decline from AIM your script should abort and notify the user of the error and have them try again with a new credit card.
If a subscription payment is declined the subscription will be suspended. If you update the subscription before the next scheduled payment is due the missed payment will automatically be attempted again and if successful the subscription will be active again.
There is no way through any current API to check the status of a subscription. It currently can only be done through the control panel. It is on their to do list so this may change in the future.
UPDATE 2011-12-01
The ARB API now offers the ARBGetSubscriptionStatusRequest call to get a subscription's status.