[Mobile Payments] Display reader input method message when reader is ready #8136
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This modal was identical to the TapOrInsert modal, so can be removed.
joshheald
added
type: bug
Previously, we did not take account of the ReaderInputOptions returned to us by the Stripe Terminal API, instead we always displayed “Tap, insert, or swipe to pay”, even when those options were not supported, or the SDK was requesting a different method. This change passes the ReaderInputOptions to the View Model concerned with showing this message to the merchant, and converts the various supported options into specific localized strings, along with a (currently unused) default of “Present card to pay”. To see this in action, compare the messages shown when using a US card reader (M2 or chipper, which both support swipe reads) to a CA reader (which only supports tap or insert reads.)
joshheald
force-pushed
the
issue/8116-restore-ability-to-display-reader-messages
branch
from
44d4e53 to
95f5e23
Compare
joshheald
changed the base branch from
trunk
to
task/update-StripeTerminal-to-2.14
Collaborator
You can test the changes from this Pull Request by:
|
Contributor
|
Hi @joshheald, I used a CA store, but still I see Tap, insert or swipe to pay, same as with an American store:
|
Contributor
Author
@toupper thanks for the review It's more down to the reader than the country... CA is just because we use WisePad 3 there. Are you using a real WisePad 3, or the simulated reader? Edit – I've updated the testing instructions to specify this |
Generated by 🚫 dangerJS |
Contributor
|
@joshheald Now I could test it with the physical readers and it works as expected. LGTM! |
toupper
approved these changes
Nov 17, 2022
joshheald
deleted the
issue/8116-restore-ability-to-display-reader-messages
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #8116
Description
In #8115, we started to use
waitingForInputas the trigger to show theReader is readyalert. When I checked the code, thewaitingForInputmessage is accompanied by the types of input which can be used, and these should be presented to the user.There was no way for the waitingForInput action to pass on the specific instruction from the SDK, e.g. insert card. It's likely that we used the default string of
Tap, insert or swipe card to paybecause when we first added IPP, we only supported readers with all three modes.Beyond the existing message, this PR adds specific messages for
Tap or insert card to pay(used by the WisePad 3 in Canada, which has no swipe facility) andTaporInsertalone, in case of specific requests for these payment methods, e.g. by Tap to Pay, or a case when the chip is required..Testing instructions
Using a US store with a M2 or Chipper reader
Menu > Payments > Collect paymentTake paymentCardReader is readymessage is shown withTap, insert or swipeas mentioned payment methods.Using a CA store with a WisePad 3 reader
Repeat steps 1-4 above, but observe that the message shows only
Tap or insertpayment methodsScreenshots
payments-with-variable-payment-method-messages.mp4
RELEASE-NOTES.txtif necessary.