Closed Bug 979154 Opened 11 years ago Closed 10 years ago

[B2G][NFC][User Story]: Add couponing (EMV+MIFARE) to tap-to-pay

Categories

(Firefox OS Graveyard :: NFC, defect)

Product:
Firefox OS Graveyard
Component:
NFC
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(feature-b2g:2.1, tracking-b2g:backlog)

Status:
VERIFIED FIXED
Milestone:
2.1 S3 (29aug)
Project Flags:
feature-b2g 2.1
tracking-b2g backlog

People

(Reporter: skamat, Assigned: vchang)

References

Details

(Keywords: feature, Whiteboard: [ucid:NFC13, FT:RIL][U2][2.1-feature-qa+])

User Story

This use case adds couponing (EMV+MIFARE) to the following user story. (Bug 979152)

As a user, I would like to use Tap-to-pay functionality (with HCI event triggering) to make payments at various points of sale. There will be a visual confirmation to the user that the transaction succeeded or failed.

Acceptance Criteria

AC1: If the settings has NFC turned on with appropriate secure elements (payments + couponing data), the user accesses this functionality simply by tapping at an enabled point of sale.
AC2: There will be a visual confirmation to the user that the transaction succeeded or failed. During the payment transaction, the user should see the reduced price (after coupon). The reflected price should be recorded in the payment & couponing history of the app.
AC3: The reader (payment terminal) equipment also needs to record a successful transaction.
This use case adds couponing (EMV+MIFARE) to the following user story. (Bug 979152) As a user, I would like to use Tap-to-pay functionality (with HCI event triggering) to make payments at various points of sale. There will be a visual confirmation to the user that the transaction succeeded or failed.
Acceptance Criteria AC1: If the settings has NFC turned on with appropriate secure elements (payments + couponing data), the user accesses this functionality simply by tapping at an enabled point of sale. AC2: There will be a visual confirmation to the user that the transaction succeeded or failed. During the payment transaction, the user should see the reduced price (after coupon). The reflected price should be recorded in the payment & couponing history of the app. AC3: The reader (payment terminal) equipment also needs to record a successful transaction.
Add two high-level OS/NFC technical requirements that are closely related to supporting this user story. 1. The mobile device SHALL support SIM-based NFC Card Emulation mode as per ISO14443 Type A/B; 2. The mobile device SHALL support SIM-based NFC Card Emulation mode as per MIFARE;
Whiteboard: [ucid:NFC13, FT:RIL]
User Story: (updated)
Depends on: 979888
Depends on: 979891
blocking-b2g: --- → backlog
targeting release 2.1 Based on 979868 and 979888, of which 979868 has landed)
feature-b2g: --- → 2.1
Whiteboard: [ucid:NFC13, FT:RIL] → [ucid:NFC13, FT:RIL][U2]
No longer depends on: 1029947
QA Whiteboard: [COM=NFC]
We are developing 2.1. EM should take this bug.
Assignee: nobody → vchang
QA Whiteboard: [COM=NFC] → [COM=NFC][2.1-feature-qa+]
Flags: in-moztrap?(ashiue)
QA Contact: ashiue
QA Whiteboard: [COM=NFC][2.1-feature-qa+] → [COM=NFC]
Whiteboard: [ucid:NFC13, FT:RIL][U2] → [ucid:NFC13, FT:RIL][U2][2.1-feature-qa+]
Target Milestone: --- → 2.1 S3 (29aug)
Flags: in-moztrap?(ashiue) → in-moztrap-
Alison - Can you provide an explanation here on why you don't think we should provide moztrap coverage for this bug?
Flags: needinfo?(ashiue)
All the depended bugs have been fixed. Change the status to resolved fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Jason Smith [:jsmith] from comment #5) > Alison - Can you provide an explanation here on why you don't think we > should provide moztrap coverage for this bug? Since the flow of couponing user story needs POS system with special price logic and EMV(this related to credit card corporation), but actually, how do those third-party applications do the communication is not what FireFox OS can control, after discussing with developers, QA testing from Mozilla would focus on making sure our device could provide ISO14443 and MIFARE communication channels at any situation, the testing would cover by bug 979157 and bug 979152.
Flags: needinfo?(ashiue)
Hi Sandip, Per comment 7, current environment we have are not sufficient to pass acceptance criteria. But actually it's not on FxOS, but on the payment terminal and SIM app. In such case, is it ok to set "VERIFIED FIXED"?
Flags: needinfo?(skamat)
Wesley - Given that dependent FxOS work has completed I am okay with marking this task completed this task, However, I am not sure how we can call it "verified" yet. Unless Ming has ideas, we could mark it "WorksforMe" perhaps. Ming, Any guidance here on how we can proceed?
Flags: needinfo?(skamat) → needinfo?(ming.yin)
I believe, the same question should be raised also for other payment related user stories(979158/979152/979157) too. The reason is due to the limited testing environment for payment/ticketing/couponing on QA side, right? Can we do following for payment testing? 1) QA mainly focuses on the payment related OS feature verification; 2) The partner will test/verfiy the user-story in their commercial environemnt, where the EMV payment/coupoing acceptance systems are available. (Krzysztof from DT has already done several such tests in commercial environment and recorded videos and logs.) Based on the QA testing and the tests done by partner, the status "VERIFIED FIXED" is OK for me for this user-story.
Flags: needinfo?(ming.yin)
Unable to verify this bug. Do not have access to a tap-to-pay app. Also not all depends on bugs have been verified yet
QA Whiteboard: [COM=NFC] → [COM=NFC][QAnalyst-verify-][QAnalyst-Triage?]
Flags: needinfo?(ktucker)
According to comment 10, marked this user story as VERIFIED.
Status: RESOLVED → VERIFIED
QA Whiteboard: [COM=NFC][QAnalyst-verify-][QAnalyst-Triage?] → [COM=NFC][QAnalyst-verify-][QAnalyst-Triage+]
Flags: needinfo?(ktucker)
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.