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

Make STPSource conform to STPPaymentMethod, exposing labels & images #976

Merged
merged 9 commits into from
Aug 3, 2018

Conversation

joeydong-stripe
Copy link
Contributor

@joeydong-stripe joeydong-stripe commented Jun 26, 2018

Summary

Adds STPPaymentMethod protocol implementation for STPSource. In particular, it enables source.label, source.image, and source.templateImage.

There's potentially room to improve the labels & images - right now non-cards just mirror whatever the Source type is.

Motivation

Issue originally raised after extensive investigation between Joey & Fred. See individual commits. More details in IOS-816.

Testing

Automated tests added for the new functionality.

We originally made it a private implementation because the `STPPaymentMethod` protocol implementations don't return anything useful for `label` and `image` but we're going to improve on that next.
@joeydong-stripe joeydong-stripe self-assigned this Jun 26, 2018
@joeydong-stripe joeydong-stripe force-pushed the joeydong/displayableSource branch 8 times, most recently from 4583ba8 to 5922603 Compare June 27, 2018 16:55
@joeydong-stripe joeydong-stripe force-pushed the joeydong/displayableSource branch from 5922603 to 15f81a0 Compare June 27, 2018 18:48
@joeydong-stripe joeydong-stripe changed the title [WIP] Displayable STPSource Displayable STPSource Jun 27, 2018
Copy link
Contributor

@danj-stripe danj-stripe left a comment

Choose a reason for hiding this comment

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

I've left some comments with questions/suggestions.

Also, I think you have a typo in the Pull Request description. I think this is enabling source.label, not source.length.

PS: is there a reason you didn't use the Pull Request template with Summary/Motivation/Testing?

case STPSourceTypeEPS:
return @"EPS";
case STPSourceTypeMultibanco:
return @"Multibanco";
Copy link
Contributor

Choose a reason for hiding this comment

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

Do any of these need to be localizable strings?

My first thought was no, because they're brand/product names. On the other hand, I suspect it'd be weird to see "Alipay" instead of "支付宝" (according to wikipedia) in an app localized to Chinese.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, we should probably wrap them in NSLocalizedString calls in case users want to localize it themselves in a particular way.

case STPSourceTypeMultibanco:
return @"Multibanco";
case STPSourceTypeUnknown:
return [STPCard stringFromBrand:STPCardBrandUnknown];
Copy link
Contributor

Choose a reason for hiding this comment

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

wdyt about using @"Unknown" here instead of this layer of indirection with STPCardBrandUnknown?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah why not. I first put this here because I was focused on card source types but it is a little out of place in the STPSourceTypeUnknown block.

CHANGELOG.md Outdated
@@ -1,3 +1,5 @@
* Adds `STPPaymentMethod` protocol implementation for `STPSource` [#976](https://github.com/stripe/stripe-ios/pull/976)
Copy link
Contributor

Choose a reason for hiding this comment

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

wdyt about: mentioning what this accomplishes? I suspect this won't mean much to our users

case STPSourceTypeSofort:
return @"SOFORT";
case STPSourceTypeThreeDSecure:
return @"3D Secure";
Copy link
Contributor

Choose a reason for hiding this comment

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

Did you consider including more details from the source in the label strings?

3DS is an obvious one: it's wrapping a card, and the customer is probably more likely to recognize the card that's used in the Source than the fact that it was charged through 3DS. It'd also be hard for them to disambiguate if they had more than one.

I suspect the STPSourceParam factory methods are good references for what fields might be interesting on a per-SourceType basis.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I did want to include more information if available but it looks like we don't make API Version guarantees on what information is included in the source specific blocks. If I'm wrong about the guarantees, then yeah we should add them appropriately.

@joeydong-stripe joeydong-stripe force-pushed the joeydong/displayableSource branch from 2151761 to a9458b7 Compare July 12, 2018 17:27
/* Title for Payment Method screen */
"Payment Method" = "Payment Method";

/* Caption for Phone field on address form */
"Phone" = "Phone";

/* Short string for postal code (text used in non-US countries). Please keep to 8 characters or less if possible. */
Copy link
Contributor

Choose a reason for hiding this comment

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

Were these character count suggestions removed because you re-ran genstrings? I wonder if we need to move them into the STPLocalizedString call

…eSource

 Conflicts:
	CHANGELOG.md
	Tests/Tests/STPFixtures.h
	Tests/Tests/STPFixtures.m
Also, fixing `testPaymentMethodTemplateImage()` for non-Card sources. It was missing
the assertion
@danj-stripe danj-stripe self-assigned this Aug 2, 2018
@danj-stripe danj-stripe changed the title Displayable STPSource Make STPSource conform to STPPaymentMethod, exposing labels & images Aug 2, 2018
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.

lgtm

@@ -1,3 +1,6 @@
## XX.Y.Z
Copy link
Contributor

Choose a reason for hiding this comment

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

this is just a placeholder for when we make the next release?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah. I think it's better for us to update the CHANGELOG during the release process, to avoid conflicts while merging PRs, but sometimes we do it during the PR.

@danj-stripe danj-stripe merged commit df4fded into master Aug 3, 2018
@danj-stripe danj-stripe deleted the joeydong/displayableSource branch August 3, 2018 20:44
danj-stripe added a commit that referenced this pull request Aug 3, 2018
…ro from #976

Same problem as d1e3669, but they were disabled to avoid
build failures.

Now that we have a (hack/workaround) for image equality tests, use it.
danj-stripe added a commit that referenced this pull request Aug 6, 2018
…ro from #976 (#1005)

Same problem as d1e3669, but they were disabled to avoid
build failures.

Now that we have a (hack/workaround) for image equality tests, use it.
jaimepark-stripe added a commit that referenced this pull request Apr 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants