[XL] Prototype payment processing - stripe

[meyerdarcie]

Description:

As a park visitor, I want to be able to pay for my backcountry camping experience online 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.

This ticket is to look into stripe as an option.

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)

Payments now handled via Stripe or Bambora. Payments can be viewed in the administrative portal of each respective payment processor.

Acceptance Criteria:

Payment acceptance and error handling is performed by the payment processor. We have no control over this process, we can only display the errors, which is trivial/out of scope for this investigation. To see the response from the payment processor, visit the administrative portal or console log the errors.

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.

All of the above handled by the processor.

Development Checklist:

• [ ] github repo for this is set up...?? > Done
• [ ] access to stripe: stripe test space is used > Using Digitalspace's test space. Will need a BCGOV space if we continue with either processor.
• [ ] ensure this payment component can be reused - componentize? > Components come with payment processor.

Dependencies

• should be able to test some edge cases we need (without using real money) > Done, both processors have test suites.
• not public - set up in dev, test, or toolbox of existing AWS space? > Out of scope until we pick a processor.
• blocks bcgov/reserve-rec-public#10

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

• [x] 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:

• [x] 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

[JLWade]

Notes from refinement May 28, 2024:

• who do we need to talk to if this is the better choice (OCIO, NRIDS architects)
• does anyone else in gov use stripe?
• PIA's and STRA's?
• will need to document bambora versus stripe options analysis - pros/cons, costs, how good/bad is documentation, how painful would it be if/when changes are made to base tool
• are there any current issues with bambora with other gov services?
• meet with BC Registries group about their experience

[JLWade]

New ticket: bcgov/reserve-rec-public#10

• simple documentation of options analysis between payment options for backing up decision
• will be blocked by 2 prototype tickets, and likely same person doing it

[cameronpettit]

Payment processor POC now lives at https://github.com/bcgov/reserve-rec-admin/tree/payment-processor-poc. Follow the README to setup the POC on local machines.

Because this ticket turned more into a comparison between Bambora and Stripe, the POC is in a very rough draft state. It investigates how data might flow from a public facing payment terminal to an administrative portal, but a practical implementation of a payment processor may look very different.

[meyerdarcie]

Moving to done. I will take over exploration/approval/compliance advocating for Stripe over Bambora, and create any technical tickets for future sprints as we go.