-
Notifications
You must be signed in to change notification settings - Fork 999
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
Add FPX to Basic Integration #1390
Conversation
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.
Couple minor comments but overall looks good!
@param completion completion block called with status of backend call & the client secret if successful. | ||
@see https://stripe.com/docs/payments/payment-intents/ios | ||
*/ | ||
- (void)createPaymentIntentWithCompletion:(STPPaymentIntentCreationHandler)completion; | ||
- (void)createPaymentIntentWithCompletion:(STPPaymentIntentCreationHandler)completion additionalParameters:(NSString * _Nullable)additionalParameters; |
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.
Is this going to convert to swift strangely? I'd probalby expect createPaymentIntentWithAdditionalParameters:(NSString * _Nullable)additionalParameters completion:(STPPaymentIntentCreationHandler)completion;
I'd also probably expect additionalParameters
to be an NSDictionary but since this is sample backend code don't feel strongly on either of these
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.
Yeah, that was roughly my feeling. It should take a dictionary and convert all the parameters properly, but this was a quick change to make an Objective-C-only sample app work, so meh. I'm more worried about how this additional parameter adds incremental complexity to our sample app.
numberFormatter.numberStyle = .currency | ||
numberFormatter.usesGroupingSeparator = true | ||
return numberFormatter | ||
}() |
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.
👏
Stripe/STPPaymentIntentParams.m
Outdated
@@ -78,6 +81,14 @@ - (nullable NSString *)setupFutureUsageRawString { | |||
} | |||
} | |||
|
|||
- (void)configureWithPaymentResult:(STPPaymentResult *)paymentResult { | |||
if (paymentResult.paymentMethod) { | |||
_paymentMethodId = paymentResult.paymentMethod.stripeId; |
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.
copy
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.
good catch, thanks!
if (self.card != nil) { | ||
STPCardBrand brand = [STPCardValidator brandForNumber:self.card.number]; | ||
NSString *brandString = STPStringFromCardBrand(brand); | ||
return [NSString stringWithFormat:@"%@ %@", brandString, self.card.last4]; |
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.
this should probably be localized. Okay for a follopwup
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.
This isn't localized in STPPaymentMethod.m or STPCard.m either, though we do localize the similar "%@ Ending In %@" strings. We should probably localize all of them.
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.
👍
self.titleLabel.text = STPLocalizedString(@"Online Banking (FPX)", @"Button to pay with a Bank Account (using FPX)."); | ||
|
||
// Checkmark icon | ||
self.checkmarkIcon.hidden = YES; |
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.
does this get reset if the cell is reused for a non-FPX option?
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.
It does! For selectable cells, the hidden field is populated with the selected state of the card.
@@ -20,7 +20,8 @@ NS_ASSUME_NONNULL_BEGIN | |||
|
|||
+ (instancetype)tupleWithPaymentOptions:(NSArray<id<STPPaymentOption>> *)paymentOptions | |||
selectedPaymentOption:(nullable id<STPPaymentOption>)selectedPaymentOption | |||
addApplePayOption:(BOOL)applePayEnabled; | |||
addApplePayOption:(BOOL)applePayEnabled |
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.
can we get rid of the apple pay specific param and just use additionalOptions?
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 did originally, but found that applePayEnabled
is a little more complex than that. We need the appleMerchantIdentifier
from STPPaymentConfiguration, which the STPPaymentOptionTuple isn't aware of, and I don't really want to pipe it all the way down here.
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.
For reference:
- (BOOL)applePayEnabled {
return self.appleMerchantIdentifier &&
(self.additionalPaymentOptions & STPPaymentOptionTypeApplePay) &&
[Stripe deviceSupportsApplePay];
}
return [self.paymentOptions filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(id<STPPaymentOption> _Nullable evaluatedObject, NSDictionary<NSString *,id> * __unused _Nullable bindings) { | ||
if ([evaluatedObject isKindOfClass:[STPPaymentMethodParams class]]) { | ||
STPPaymentMethodParams *paymentMethodParams = (STPPaymentMethodParams *)evaluatedObject; | ||
if (paymentMethodParams.type == STPPaymentMethodTypeFPX) { |
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.
can this be like if (paymentMethodParams.type != STPPaymentMethodTypeCard)
so we don't accidentally regress it when adding a new type'?
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.
Sure, that'd be more forward-thinking. (Though a regression here would be very visible!)
return [self.paymentOptions filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(id<STPPaymentOption> _Nullable evaluatedObject, NSDictionary<NSString *,id> * __unused _Nullable bindings) { | ||
if ([evaluatedObject isKindOfClass:[STPPaymentMethodParams class]]) { | ||
STPPaymentMethodParams *paymentMethodParams = (STPPaymentMethodParams *)evaluatedObject; | ||
if (paymentMethodParams.type == STPPaymentMethodTypeFPX) { |
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 think == STPPaymentMethodTypeFPX
makes sense here since we don't have basic integration support for other apms (would maybe add a comment to that effect)
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.
Makes sense.
} | ||
} | ||
return YES; | ||
return NO; |
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.
couldn'e this still be yes in case it's an STPPaymentMethod
?
} | ||
} | ||
return NO; | ||
return YES; |
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.
ah there we go 🙃
) Long-term fix is to revert this commit, add `animated: Bool` params to SectionContainerView, AddressSection, etc., and make the `updateBillingSameAsShippingDefaultAddress` call in `AddPaymentMethodViewController.willAppear` pass `animated: false`. If it animates during viewWillAppear, the view controller presentation animation becomes glitchy.
Summary
Adds FPX to STPPaymentOptionsViewController.
STPPaymentOptionType
.STPPaymentOptionTypeAll
is nowSTPPaymentOptionTypeDefault
and does not include FPX. This is a breaking change, and we've added a deprecation warning with guidance to switch to.Default
.STPPaymentResult
is now initialized from an<STPPaymentOption>
and filled with either anSTPPaymentMethod
or anSTPPaymentMethodParams
. This means.paymentMethod
is now optional, which is a breaking change, but no one will encounter a nil.paymentMethod
unless they're adopting FPX. We've added a convenience function,[STPPaymentIntentParams configureWithPaymentResult:]
, to easily set up an STPPaymentIntentParams from an STPPaymentResult. (See CheckoutViewController.swift for usage. We'll want to update the stripe.com docs to match.)Country
selector in Settings, which allows the user to set the currency tomyr
for FPX testing. The selected country is also passed to example-ios-backend to configure the allowed_payment_methods and currency.Testing
Tested in Custom Integration and Standard Integration apps.