#josha_code
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1344004373189099551
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Here is the full code sample:
let merchantIdentifier = "com.mudflap.mudflap"
let paymentRequest = StripeAPI.paymentRequest(withMerchantIdentifier: merchantIdentifier, country: "US", currency: "USD")
paymentRequest.paymentSummaryItems = [
// PKPaymentSummaryItem(label: "iHats, Inc", amount: 50.00),
PKDeferredPaymentSummaryItem(label: "Test", amount: NSDecimalNumber(string: "0.01"), type: .pending)
]
if let applePayContext = STPApplePayContext(paymentRequest: paymentRequest, delegate: self) {
applePayContext.presentApplePay(completion: { })
print("Presented applePayContext")
} else {
print("DID NOT present applePayContext")
}
With PKPaymentSummaryItem, I get Presented applePayContext.
With PKDeferredPaymentSummaryItem, I get DID NOT present applePayContext.
Hi! Do you get an error? What does happen?
I'm seeking confirmation of whether the Stripe SDK supports PKDeferredPaymentSummaryItem and I'm doing it wrong OR the Stripe SDK does NOT support PKDeferredPaymentSummaryItem.
Following on with my description from above, it appears that STPApplePayContext initializes to nil when I give the Stripe SDK a PKDeferredPaymentSummaryItem, which leads to me getting into the DID NOT present applePayContext state.
Debugging this futher, it seems like this is the failing line in Stripe's SDK:
https://github.com/stripe/stripe-ios/blob/master/StripeApplePay/StripeApplePay/Source/ApplePayContext/STPApplePayContext.swift#L137
When I pass in a PKPaymentSummaryItem, this returns a non-nil value.
When I pass in a PKDeferredPaymentSummaryItem, this returns a nil value.
On inspecting my paymentRequest.supportedNetworks in both cases, they both have the same values.
I don't believe we directly support them, as we handle that logic internally but let me confirm.
I can't find any mention of this at all in our iOS SDK either - but I feel like this is something that the SDK supports in a different way. ๐ค But also I need to jet; hopefully my colleague can be more helpful on this! Cheers!
Thanks @glad coral
hi! catching up on this thread now
Ok, I actually figured it out.
oh great! do you mind filling me in?
As it turns out, PKPaymentAuthorizationViewController wants the PKDeferredPaymentSummaryItems given to it to have a value assigned for their deferredDate, like so:
let merchantIdentifier = "com.mudflap.mudflap"
let paymentRequest = StripeAPI.paymentRequest(withMerchantIdentifier: merchantIdentifier, country: "US", currency: "USD")
let deferredPaymentSummary = PKDeferredPaymentSummaryItem(label: "Deesul", amount: .zero, type: .pending)
deferredPaymentSummary.deferredDate = .distantFuture
paymentRequest.paymentSummaryItems = [
deferredPaymentSummary
]
In my original code sample, I was not assigning a deferredDate and, so, the line I linked above (in the Stripe SDK) would fail to initalize.
(Perhaps a useful call out in Stripe's documentation? This is decidedly Apple's behavior, but it's obscure and Stripe wraps over it so hard to tell who's responsible.)
BUT... I have one last question: We've been in touch with Stripe reps who are trying to get us to modernize our SDK usage (primarily, moving to PaymentSheet). I just wanted to confirm if STPApplePayContext is considered a 'legacy' SDK that Stripe wants us to avoid?
i don't think so - our guides still reference it:
https://docs.stripe.com/apple-pay
ok good deal. thank you for the confirmation and for everyone's help! i think we're good here.