-
Notifications
You must be signed in to change notification settings - Fork 664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix mandate handling in Payment Element
#10171
Fix mandate handling in Payment Element
#10171
Conversation
Diffuse output:
APK
DEX
|
beb790d
to
7258aae
Compare
requiresMandate
to true
for public API PaymentMethod
for Klarna
, 'AmazonPay', and CashApp
requiresMandate
to true
for public API PaymentMethod
for Klarna
, AmazonPay
, CashApp
, and RevolutPay
requiresMandate
to true
for public API PaymentMethod
for Klarna
, AmazonPay
, CashApp
, and RevolutPay
requiresMandate
to true
for public PaymentMethod
API for Klarna
, AmazonPay
, CashApp
, and RevolutPay
Seems like nothing broke! Think I can add one E2E test for each that tests in PI w/ SFU with client-side confirmation to cover these cases in the future. |
de39ab8
to
c40b474
Compare
requiresMandate
to true
for public PaymentMethod
API for Klarna
, AmazonPay
, CashApp
, and RevolutPay
Payment Element
StripeIntent.Usage.OneTime -> false | ||
StripeIntent.Usage.OnSession, | ||
StripeIntent.Usage.OffSession -> true | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, we have this OneTime
usage value that I don't think the API returns anymore but is defined. We should probably remove it? Would need to evaluate outside this PR.
SetupIntent.ClientSecret.isMatch(clientSecret) -> { | ||
ConfirmSetupIntentParamsFactory(clientSecret) | ||
intent is SetupIntent && SetupIntent.ClientSecret.isMatch(clientSecret) -> { | ||
ConfirmSetupIntentParamsFactory(clientSecret, intent) | ||
} | ||
else -> { | ||
error("Encountered an invalid client secret \"$clientSecret\"") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of all the changes, this feels the riskiest somehow. I don't think we have any unexpected issues with the client secret type being different than the actual intent type. We could just rely on the client secret from the intent itself but the StripeIntent
type has it as potentially nullable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it would fail server side if this happened, right? Can we either change this to a client side error, rather than crashing, or just assume it's right?
c40b474
to
d0a80d4
Compare
), | ||
savePaymentMethod = null, | ||
setupFutureUsage = null, | ||
clientSecret = "seti_123_secret_123", | ||
) | ||
) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failed after adding the intent type check above. Needed to update to actually create CreateSetupIntentParams
payments-core/src/test/java/com/stripe/android/ConfirmSetupIntentParamsFactoryTest.kt
Outdated
Show resolved
Hide resolved
854fd21
to
355c5b6
Compare
@@ -308,7 +308,7 @@ constructor( | |||
"paypal", | |||
isReusable = false, | |||
isVoucher = false, | |||
requiresMandate = false, | |||
requiresMandate = true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Paypal
is another one that was also not handled properly.
@@ -86,7 +86,5 @@ internal fun confirmSetupIntentParams(): RequestMatcher { | |||
return RequestMatchers.composite( | |||
bodyPart("payment_method", "pm_12345"), | |||
bodyPart("client_secret", "seti_12345_secret_12345"), | |||
bodyPart(urlEncode("mandate_data[customer_acceptance][type]"), "online"), | |||
bodyPart(urlEncode("mandate_data[customer_acceptance][online][infer_from_client]"), "true"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A result of the changes we made. mandate_data
is now only sent when required rather than all the time with SetupIntent
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this against cards in Payment Element and it ran fine without mandate_data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we show mandate data for cards now, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do but I don't think that it is server-recognized.
c429a00
to
69d7816
Compare
69d7816
to
f339063
Compare
Summary
Ensures that
MandateData
is only sent for intents intending to setup the providedPaymentMethod
for future usage. Also setsrequiresMandate
totrue
for publicPaymentMethod
API forKlarna
,AmazonPay
,CashApp
, andRevolutPay
.Motivation
Fix PI w/ SFU for deferred intents.
Testing