B2G/QA/WebAPI Test Plan/WebPayment

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

Strategy

• 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

Edge Cases

• 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

Signoff Criteria

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

Test Case Management

• A generic test application will need to be created that allows for making various in-app purchases and refunds that represent a wide variety of test cases

Open Questions

• 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?