[XL] Prototype payment processing

[JLWade]

Description:

As a park visitor, I want to be able to pay for my backcountry camping experience on line so that I do not need to pay in the parking lot and can secure a reservation.

Payment processing is necessary for next iteration of reservation service components and a pattern we have not yet done - hence the idea for trying this out as a prototype. This prototype will be used for testing with users and adding to future prototypes of larger workflows (eg. full bookings). It is meant to be iterated and improved upon.

Use cases for prototype:

• happy path - success all is correct no errors
• wrong info entered (error) (for MVP, just generic errors)
  • wrong credit card number
  • wrong cvs number
  • wrong name
  • wrong address
• no credit available (error)
• bots (likely not a thing)

Acceptance Criteria:

Given I am a visitor who wants to purchase something When I click to purchase an item Then I am taken to a payment screen/form where I can enter my information to pay.

Given I am a visitor who wants to purchase something When I fill out my payment info correctly and have credit and click submit/buy/purchase/next Then I get confirmation of my successful payment via text on the next screen.

Given I am a visitor who wants to purchase something When I fill out my payment info incorrectly and click submit/buy/purchase/next Then I get an error message saying my info is incorrect and can try again.

Given I am a visitor who wants to purchase something When I am trying to use an invalid credit card and click submit/buy/purchase/next Then I get an error message saying the card is invalid and can try again.

Given I am a visitor who wants to purchase something When I am trying to use a maxed out credit card and click submit/buy/purchase/next Then I get an error message saying the card is maxed and can try again.

Given I am a robot When I am trying to spam the site by clicking purchase Then I get turned away.

Development Checklist:

• [ ] github repo for this is set up...??
• [ ] access to bambora: bambora test space is used
• [ ] ensure this payment component can be reused - componentize?

Dependencies

• should be able to test some edge cases we need (without using real money)
• not public - set up in dev, test, or toolbox of existing AWS space?

Wireframe(s):

Workflows:

Prototype will be scoped to just payment portion of workflow:

• select an item --> click purchase -->payment form --> fill out payment info ---> pay --> success/confirmation of purchase

Notes:

• for prototype, let's not look at the scenario of losing wifi mid process

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

• [ ] User story is included
• [ ] User role and type are identified
• [ ] Acceptance criteria are included
• [ ] Wireframes are included
• [ ] Design / Solution is accepted by Product Owner
• [ ] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done

• In progress:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] UI meets accessibility requirements
  • [ ] Unit tests are written
  • [ ] Work is traceable in GitHub
  • [ ] PR linked to ticket number
  • [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• Code review:
  • [ ] Code is peer reviewed and has passed CI/CD tests
• QA:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Code is potentially shippable to the production environment
  • [ ] Functional features have been tested and passed by QA
  • [ ] UI components tested by designer
  • [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• PO Review:
  • [ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
  • [ ] Reviewed and approved by Product Owner

[Dianadec]

• Using bambora
• should be able to test every edge case we need (without using real money)
• Testing with bambora is free
• Come up with general workflow
• Pull in research notes that Mark has already done

where to build?

• ~Tools. We no longer have sandbox~
• local, developer machine ~make sure it works on AWS~

Need to figure out:

• where to put this in to our workflow
• lots of research on bambora (devs only- looking at docs)

Ask res team:

• any issues with payments system so far? - so we can flag any issues with payment flow
• they also use bambora

down the road:

• testing out refunds

[Dianadec]

Ideas to move forward:

• Create a flowchart based on the workflow noted in the description above. (then we can more easily identify other edge cases) Will need to create a ticket for the flowchart piece

[cameronpettit]

Understand this is potentially blocked by bcgov/reserve-rec-public#9 - I need to learn what Bambora is capable of before I build a flowchart we are going to adhere to. This might be a ticket that gets done simultaneously with bcgov/reserve-rec-public#9

[Dianadec]

This has been completed for bambora and now we will do it with Stripe. cc @cameronpettit @meyerdarcie