WebPayment

Summary

Lead	Jason Smith (irc: jsmith)
API Description	Allows for monetary payments for a virtual good
API Developer	Fernando Jimenez Moreno
API Project Page	WebPayment
API Tracking Bugs	Bug 767818
API Status	Landed

API testing to ensure the JS API handles general valid and invalid input cases with the right success/error callbacks
JWT generation testing to analyze the different values allowed to be used in calling nav.mozPay and its resulting effects
End-to-End functional testing with mozPay and trustworthy UI - Ensure that end to end flows integrating across BlueVia, Marketplace, and Firefox OS fit together as a whole
Availability and Resilience end-to-end testing - Many distributed components are involved in the web payments in mozPay, so we should be able downtime of a component or problems that a component in the process generates gracefully
Penetration Testing - There's trust on identification, receipt expiration, etc involved here, so we'll need to test for risks that could occur in any of those factors
User scenarios and test cases that involve Marketplace's use of nav.mozPay is out of scope in this test plan - see Krupa Raj for more information on the testing approach there

Multiple payments chained together
Different payment providers (i.e. JWT typ), valid vs. invalid
Payment Provider Server Downtime or Failure
Invalid JWT requests
Switching app contexts post the call of mozPay
Interception and altering of content to be rendered within trustworthy UI chrome
Valid vs. invalid application keys
Expired vs. Non-Expired Payment Requests and Refunds
Different country codes
Different locale text with JWT request
Optional vs. required parameters for JWT request
Default pricing vs. locale-specific pricing
Different country currencies
Completed vs. Canceled Purchases
Marketplace Server Downtime or Failure
Registered application for in-app payments vs. non-registered
Valid vs. invalid postback and chargeback URLs on successful payments and refunds
Default price vs. no default price
Valid vs. invalid amounts
Application server response vs. no response on transaction response confirmation
Successful vs. unsuccessful authentication
Valid vs. invalid transaction IDs for a refund
Masquerading as a valid seller, when in reality the seller is not the one to receive the purchase in app X
Masquerading as a valid buyer, when in reality the buyer is not the one making the purchase from X account
Replaying of in-app purchase requests and refunds multiple times

All basecamp blockers are closed
All smoke tests and basic functional tests are ran without finding any basecamp blockers

Test cases themselves will be documented in a spreadsheet referenced below
For tracking of test case results that do not run a consistent build run, they shall be tracked as references below in spreadsheet form
For test cases that intend to be ran repeatedly on builds, they shall be tracked in John's global test suite spreadsheet if any of these payment tests become smoke or extended smoke tests for Firefox OS at large (which will likely be the case down the line)

A generic test application is going to be needed that allows for various different JWT requests for payments and refunds
A mock payment provider will be needed to be able to write automation against for this payment API. Additionally, it will be needed probably to help diagnose problems that are in the API vs. BlueVia's side
Control over the payment provider test server will be needed to be able understand what's going on server side and be able to affect it as needed (e.g. invoke downtime or incorrect values)

Automation is primarily going to target mozPay's use of the mock payment provider
The trustworthy UI is not being tested in automation, but the events generated to cause the UI alter would be
My current hunch is that mochitests could probably be used here for automation

Does the trustworthy UI provide any context of where the HTML 5 content served inside the UI is from? In other words, how do I know the content I've received is safe or not? Is the URL of the content shown in the trustworthy UI to mitigate this?
How exactly does the identity pieces affect the in-app payments flow? I've noticed it's stated it's the responsibility of the "payment provider" - from the context of mozPay, is that a black box then?
What's the purpose of productdata? How does it affect the in-app purchase?
How exactly does the application server send the 200 OK with the order ID back to the payment provider?