I am using Rails 7 and the Pay gem to create an auction/bidding website. A user places a bid, and through pay gem/stripe I am setting up a PaymentIntent and setting the capture_method as "manual". If the user is outbid then we cancel that PaymentIntent and setup a new one for the new bid. When the user wins the bid then we capture that PaymentIntent. All works well for a use case where bids are flowing in regularly.
But in testing I have come across the situation where the PaymentIntent is automatically canceling after a 7 day expiration period. There could be a situation where the auction goes for a month and so the first few bid(s) sit there for more than 7 days and I would rather them not be canceled.
Is it just a simple solution as setting up a delayed job that runs before 7 days where it cancels and creates a new PaymentIntent? Seems like it's straight forward but I worry about the users credit card statement and seeing authorized charges coming in and out.
Looking through Stripe documentation I know that if using Terminal you can request an extended_authorization, but we aren't using Terminal obviously. But not seeing a way to reauthorize instead of capture a PaymentIntent
Overall you have two options:
Cancel and re-authorize as you stated. Yes this can lead to confusion for the Ccstomer if they see multiple auth's on their statement. It is up to the issuer for when they drop those canceled auth's off the statement.
Use a SetupIntent to collect a payment method ahead of time and then charge it once the bidding is complete. The challenge here is that there is a chance that the payment method is set up successfully but then the issuer decides to decline the actual charge at which point you would need to bring your customer back on-session to collect a new payment method and charge that one.
I'm building a react native app that has a 1 month subscription component. I have integrated into the apple API to get the receipts but I have one question I can't seem to figure out in test mode. Probably a newbie question but here we go...
When a user has an auto-renewing subscription and I call the Apple API there is the latest_receipt_info.
Will I get a new one every month? if so when does it come through?
So will all I have to do is call the Apple API, grab the latest transaction from latest_receipt_info and look at the "expires_date" field. If we are still before this date then I assume the subscription is still active? Can it be this simple to see if a subscription is active or not?
I've seen talks online about a "cancellation_date_ms" field but I can't seem to find it in sandbox mode, but why would this be needed if I just use the logic I stated above?
You can get an updated receipt any time by calling Apple with receipt data from the application, even if you send older data Apple always sends you the latest receipt.
You can check for the expiration date within, however it is the case if a user gets a refund the expiration date may still be in the future - in that case you'd be sent the cancellation_date_ms as well, so you should look out for that.
To get a better understanding of what all can be in latest_receipt_info, read through the entries in here, search for responseBody.latest_receipt_info:
https://www.namiml.com/blog/app-store-verify-receipt-definitive-guide
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.
I've been reading the various threads on in-app purchases auto-renewal subscriptions, and I think I've pieced together most of the information I need, but there are a few missing pieces. I'm hoping someone can help me.
The situation:
I have various subscription packages the user can subscribe to (e.g., package A for £1 a month, package B for £2 a month, etc.). I store the user's subscription information in my database. When the user logs in, I check which package he's on and if it's expired or not. My website, android and iOS all use the same database, hence this approach seems to make sense.
Subscribing users via in-app purchase seems straight forward enough. I check paymentQueue and once the payment is cleared, I can update my database.
My questions:
1) My understanding is the user can use iTunes to manage their subscription. Say, they go in to iTunes and cancel their subscription, how can I be notified so I can update my database? Do I need a daemon that checks expired subscriptions to see if the user renewed?
2) If the user wants to upgrade their subscription from Package A to Package B, how do I handle the pricing? Say on Jan 1st, they buy Package A, I charge them £1.00 and set the expiry date to Jan. 31st. On Jan. 15th, they want to upgrade to package B via in-app purchase. Ideally, I would charge them £2 for Package B minus £0.50 of credit they have for Package A and set the new expiry date to feb 14th. However, Apple forces me to associate each package with a tier price. How can I handle this? I don't want the user to wait until the end of the month to put them on a higher tier package...if they upgraded mid-month, it means they want the new content package B will deliver to them immediately.
Any help appreciated!
Thanks!
1) Yes you'll have to reverify your receipt check out the Receipt Validation Programming Guide in the documentation. They mention some important keys:
status - 0 if receipt is valid, or an error code
receipt - JSON response of the receipt
latest_receipt (auto-renewable only) - base 64 encoded receipt for the most recent renewal
latest_receipt_info - JSON version of latest_receipt
With this information, when a purchase is made, send the receipt to your backend for validation, the backend will keep the receipt in the DB and verify with status = 0 that it's a valid receipt. From there, every x days you can validate that receipt with a chron job, daemon, etc. and reverify. The response back each time will have latest_receipt_info that you now need to save to your DB so you have an up-to-date receipt for the next check in x days. This way you will always have the latest receipt. There is no instant notification for telling when a user cancels a subscription, but with this you'll know every x days if they have the subscription still.
2) Pricing like this unfortunately can't be handled. It was not intended for a user to "upgrade" with subscriptions - each subscription is access to it's own exclusive content as of this writing. However, if a customer emails in and complains about it, you could ask for their user name and figure out in your DB if this user has indeed upgraded mid-month and reimburse them appropriately. Very old-school and not feasible for a big user base, but hopefully you won't have that many and can keep them happy.
EDITED
For the second question, Apple's auto-renewable subscription system does not technically offer upgradeable plans between different products.
Every subscription is a stand alone product and it's up to the user to turn on/off subscriptions manually using the Subscription Manager in the iTunes Store.
However if package A and package B offer the exact same content only different duration than what ajay_nasa said is correct, you can create an single auto-subscription product with different duration options. If the user is on 1 month subscription and then the user tries to change to 2-months subscription they will get the following error message asking them go to the App Store's subscriptions manager
So basically the ONLY place the user can actually change the subscription's length is in the App Store. Whether Apple decide to pro-rate the amount left on the old subscription or just append it to the current one is really up to Apple. You need to make sure the user have access to the subscription as long as it's active by reading the Original Purchase Date and Subscription Expiration Date field from each receipt entry and determining the start and end dates of the subscription.
Answering question 1, you can verify subscription receipts in the same way as other IAP, but you'll need to check it periodically to see if the subscription has expired (the verification will tell you if it's expired).
There is more info on the Apple docs here:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html
Actually, Apple's auto-renewable subscription system does offer upgradeable plans.
To achieve this we simply should add duration in existing Auto-Renewable Subscription. Every Auto-Renewable Subscription could be family of Subscriptions so whenever developer wants to achieve upgradation in subscription he should add duration in existing Auto-Renewable Subscription with different productID.
Whenever, user upgrade his plan in between the month then his upgrade plan will be automatically works from next month.
Answering to your question #1
Recently Apple launched a feature to enable server notification whenever the subscription is renewed. However, the subscription should be in-app.
See the links given below for your reference:
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
&
https://itunespartner.apple.com/en/apps/news/45333106?sc_cid=ITC-AP-ENREC
We Need to Check Cancellation-Date provided in Receipt.
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.