-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
base: beta
Are you sure you want to change the base?
Conversation
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) { |
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'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...
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.
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.
… tap-to-pay check
Any update on this? |
@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. |
@yelrom0 Is there anything I can do to help? I'd love to help get this merged. Thanks |
Sorry to bother again, I'd like to push this feature forward. How can I help? Thanks |