I am implementing Apple Pay in our iOS Native app.
I create PKPaymentRequest object, and display the Apple Pay payment sheet successfully.
After I authorize it by Touch ID, I can get the payment token.
After I send this token to payment provider, it will shows [processing] on payment sheet.
All things work well.
But when the server-side spend longer than 30 seconds,
it will show error dialogue on payment sheet.
My question is that is there a timeout time for Token payment process? If Yes, is it 30 seconds?
Lu
Yes.
The onpaymentauthorized function must complete the payment and respond by calling completePayment before the 30 second timeout, after which a message appears stating that the payment could not be completed.
https://developer.apple.com/documentation/apple_pay_on_the_web/applepaysession/1778020-onpaymentauthorized
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
We are trying to use Apple's subscription status url.
We have setup our server to accept the url we provided in the app page and made sure the server is compatible with ATS requirements.
A post test with Postman works. (we see the request and a test json received on our end)
However we are still not receiving any notifications updates from Apple upon renewal (not even initial_buy).
Seen some questions from last year but no valid solution. Does anyone had this problem lately and solved it?
I can't make a comment, and it's hard to see if this is the case here without knowing if you are actually receiving NOTHING at your script, or just receiving no data in $_POST.
If the latter, this should work:
$data = file_get_contents('php://input');
Then you should be able to work with the data by calling json_decode or doing whatever you want with it.
I ran into the same problem. I thought that Apple would call our webhook whenever a new subscription charge is processed (similar to how Paypal, Stripe, Android etc work). But that's a mistake. According to this technical note:
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_
The App Store attempts to charge the user account 24 hours before an auto-renewing subscription expires. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into the expired state.
So Apple will only notify this endpoint when
a new subscription is created (at least that's the case for us, but we have a trial offer)
the subscription status changes from active to expired, or vice-versa.
So you have to keep track of the subscription receipts when the customer signs up. When the subscription is about to expire/has expired, call Apple's receipt validation endpoint to fetch the new receipt. If the receipt says the subscription expired, your webhook should be notified when the user reactivates it.
Is it possible to make user pre-authorize a payment in an app but the actual payment occurs at a specified later date? User will know when the payment actually takes place when she authorizes the payment.
This is not regular recurring subscription, but more like one-off payments user can make at any interval.
If not, is there a payment solution that can be integrated with iOS and offers this feature?
Using Stripe, you can save the Apple Pay token to a customer and charge it at any time. Authorization and Capture is supported with Stripe but you have to capture the funds within 7 days of authorizing it.
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.