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

Feat/add android tap and pay #123

Draft
wants to merge 16 commits into
base: beta
Choose a base branch
from

Conversation

yelrom0
Copy link

@yelrom0 yelrom0 commented Apr 26, 2023

  • Adds the StripeTerminal localmobile and core modules required for Android Tap-to-Pay
  • Updates the stripe modules to latest version
  • Fix SimulatedConfiguration object creation for constructor changes
  • This has been tested and confirmed working in GetDuck private repo/codebases

@@ -936,6 +938,38 @@ public void onFailure(@NonNull TerminalException e) {
}
}

@PluginMethod
public void tapToPaySupported(final PluginCall call) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm not really a fan of this method of determining if Tap to Pay is supported.

This will say that Tap to Pay is not supported if discoverReaders is already in progress. It would also prevent discoverReaders from happening while it is checking. Both of those could be pretty problematic in an app that auto-connects to readers on startup.

I really wish that the Terminal SDK had a built in method... When I implemented this for Tap to Pay on iOS, I just checked the iPhone model and iOS version number to "assume" if it was supported or not. Unfortunately, its not that easy on Android with different phone brands...

Copy link
Author

Choose a reason for hiding this comment

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

Yea, unfortunately this is the official Stripe way of checking.

In this instance I have added a value that is set on first run of the method call, in order to speed up subsequent calls without requiring a call to discoverReaders. Although not optimal, scanning for the compatibility/LocalMobileReader is fast (generally less than a second).

I have also added a call to cancel discoverReaders if it's already running and I have also added a call to the pendingDiscoverReaders.cancel() method within cancelDiscoverReaders before nulling pendingDiscoverReaders as Stripe includes calling that method in their docs.

If there's anything further that you would like me to change, let me know. I happy to remove this method entirely if it irks you, as it is more a nice to have check rather than a requirement.

@yelrom0 yelrom0 marked this pull request as draft May 16, 2023 22:33
@yelrom0 yelrom0 marked this pull request as ready for review May 16, 2023 23:04
@yelrom0 yelrom0 marked this pull request as draft May 17, 2023 04:51
@yllaw
Copy link

yllaw commented Jul 12, 2023

Any update on this?

@yelrom0
Copy link
Author

yelrom0 commented Jul 12, 2023

@yllaw Sorry, I haven't had much time to work on it due to priorities shifting at work for the past couple of months. I should be back onto it next week.

@yllaw
Copy link

yllaw commented Aug 9, 2023

@yelrom0 Is there anything I can do to help? I'd love to help get this merged.

Thanks

@yllaw
Copy link

yllaw commented Aug 17, 2023

Sorry to bother again,

I'd like to push this feature forward. How can I help?

Thanks

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.

3 participants