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.
Related
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.
If a user subscribes in-app, it is always refunded exactly three days later. Like this:
Intended behaviour is for the subscription to remain activated and payment not to be refunded.
Why might this happen?
Google has updated its In-App payment policies a while back and you'd need to acknowledge the payment within three days in order to retain the payment. Otherwise, your payment would get automatically refunded.
There is a new acknowledge() method available so you'd need to acknowledge your purchase.
Google states that the acknowledgement should only place after processing and granting the said features that come with In-App purchase.
See more information here.
If you do not acknowledge a purchase within three days, the user automatically receives a refund, and Google Play revokes the purchase.
https://developer.android.com/google/play/billing/billing_library_releases_notes#release-2_0
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'm working on a Rails app where I'm using stripe for creating subscriptions. Suppose, the first month the user has been charged successfully but on the second month their bank card got expired or ran out of money and they, obviously, weren't charged. How would I, as an admin of that Rails app, know if such the case has happened with one of my users?
Check api for callback after payment process, there must be something which would notify your app regarding payment(if it was succesfull or failure), and afterwards do some actions.
For example the user needs to pay $2000,
and I want to let them pay the $2000 in 5 months, and then complete the payment not charge them anymore.
This is the closes I have came close to, please let me know if this is wrong:
1- Create Subscription plans for the amounts of payment.
2- Creating a delayed job to cancel the subscription after the 5 month.
Will this be risky to do so ?
Thanks,
Yes, that's exactly how you'd want to handle it. To be more detailed...
First, you'll need to have a web hooks endpoint:
https://stripe.com/docs/webhooks
Next, you'll want to subscribe the customer to a plan like normal. We'll notify your site, via the web hooks, of when payments are made on a recurring subscription. Specifically, you'll want to watch for invoice.payment_succeeded events:
https://stripe.com/docs/api#event_types
Once a specific customer has hit the right number of payments (which you'll track on your end), you'd then issue a cancel subscription request:
https://stripe.com/docs/api#cancel_subscription
Hope that helps!
Larry
PS I work on Support at Stripe.