Skip to content
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

[17.0.0, breaking] Update API version from 2015-10-12 to 2019-05-16 #1254

Merged
merged 18 commits into from
Aug 29, 2019

Conversation

yuki-stripe
Copy link
Collaborator

Summary

Relevant changes since then:

The legal_entity property on the Account API resource has been replaced with individual, company, and business_type.

  • Some PaymentIntent statuses have been renamed
    • requires_source is now requires_payment_method
    • requires_source_action is now requires_action
    • All other statuses are unchanged

For a Source’s card[three_d_secure] property, adds recommended as a possible value. Previously, the only valid values were not supported, optional, and required.

Adds not_required as a possible redirect[status] value on the Source object. Previously, optional redirects were marked as succeeded.

(Full changelog: https://paper.dropbox.com/doc/Update-iOS-API-version-to-2019-05-16--Ahqa8fWMvo2AGLYlL1kISzoTAg-hFrNrJFf1f4dL3ZlT62YK)

Motivation

Testing

Re-ran all the functional tests

  • except STPPinManagementFunctionalTest, which is in beta (so presumably has the same behavior for all API versions). I couldn't re-record it anyways, I think it needs to be reworked to include manual steps like {Payment, Setup}IntentFunctionalTest.

Stripe/PublicHeaders/STPSourceCardDetails.h Show resolved Hide resolved
@@ -8,31 +8,54 @@

#import "STPConnectAccountParams.h"

#import "STPLegalEntityParams.h"

NS_ASSUME_NONNULL_BEGIN

@implementation STPConnectAccountParams

@synthesize additionalAPIParameters;

- (instancetype)initWithTosShownAndAccepted:(BOOL)wasAccepted
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we're changing these signatures anyway, any reason to even have the wasAccepted argument?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need it to differentiate between if the customer accepted the ToS or if the user didn't show a ToS (ie YES vs nil).

@@ -1,5 +1,8 @@
## Migration Guides

### Migrating from versions < 17.0.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm kind of inclined not to have another major version bump so soon...Maybe 16.1.0? This should only be a breaking change for Connect users right? Thoughts @yuki-stripe @davidme-stripe

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with how versioning has worked here in the past, but moving from the 2015 API sounds like an appropriate reason to increment the major version number.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely wary of fatiguing our users...there are the (minor) enum changes that Source users should update with, too. Outside of that, it should be unnoticed.

Either way, I'd like to ship this only after some confidence that 16.* won't have more bugfixes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Let's hold this patch until 16.0.* has settled and then go from there

@yuki-stripe yuki-stripe changed the title Update API version from 2015-10-12 to 2019-05-16 [17.0.0, breaking] Update API version from 2015-10-12 to 2019-05-16 Aug 9, 2019
Copy link
Contributor

@csabol-stripe csabol-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good after clarifcation on empty test file

Stripe/STPConnectAccountCompanyParams.m Show resolved Hide resolved
Tests/Tests/STPConnectAccountAddressTest.m Show resolved Hide resolved
@yuki-stripe yuki-stripe merged commit c9d3026 into master Aug 29, 2019
@yuki-stripe yuki-stripe deleted the yuki-update-api-version branch August 29, 2019 18:12
wooj-stripe pushed a commit that referenced this pull request Jul 5, 2022
If a user uploaded an ID document photo from
their camera roll or file browser which could not
be decoded by the server, the user would have no
way to select a new photo to upload because the
"Select" button would not display on the screen.
This fix resets the `DocumentUploader` when the
ViewController's `reset` method is called after
the user encounters an error state, enabling the
"Select" buttons so they can upload a new photo.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants