diff --git a/docs/README.md b/docs/README.md index 177713d68..24861359b 100644 --- a/docs/README.md +++ b/docs/README.md @@ -70,7 +70,7 @@ The Benefits application doesn't collect or store any user data directly, and we Sensitive user information exists in the following places: - To enroll in a senior discount, users need to [provide personal information to Login.gov](https://benefits.calitp.org/help#login-gov-verify). -- Users need to [provide their credit or debit card information to our payment processor (Littlepay)](https://benefits.calitp.org/help#littlepay) to enroll in a discount. +- Users need to [provide their credit or debit card information to our transit processor (Littlepay)](https://benefits.calitp.org/help#littlepay) to enroll in a discount. None of that information is accessible to the Benefits system/team. diff --git a/docs/configuration/data.md b/docs/configuration/data.md index 07f5c961c..6b5ac0303 100644 --- a/docs/configuration/data.md +++ b/docs/configuration/data.md @@ -35,7 +35,7 @@ Some configuration data is not available with the samples in the repository: - OAuth configuration to enable authentication (read more about [OAuth configuration](oauth.md)) - reCAPTCHA configuration for user-submitted forms -- Payment processor configuration for the enrollment phase +- Transit processor configuration for the enrollment phase - Amplitude configuration for capturing analytics events ## Rebuilding the configuration database locally diff --git a/docs/configuration/transit-agency.md b/docs/configuration/transit-agency.md index c105c2fd8..a72554532 100644 --- a/docs/configuration/transit-agency.md +++ b/docs/configuration/transit-agency.md @@ -8,7 +8,7 @@ Note that a `TransitAgency` model requires: - a list of supported `EligibilityType`s - a list of `EligibilityVerifier`s used to verify one of those supported eligibility types -- a `PaymentProcessor` for enrolling the user's contactless card for discounts +- a `TransitProcessor` for enrolling the user's contactless card for discounts - an `info_url` and `phone` for users to contact customer service - an SVG or PNG file of the transit agency's logo - HTML templates for various buttons, text and other user interface elements of the flow, including: @@ -21,7 +21,7 @@ Note that a `TransitAgency` model requires: - `sign_out_button_template`: _Required for auth providers_ - Sign out link button, used on any page after sign in - `sign_out_link_template`: _Required for auth providers_ - Sign out link text, used on any page after sign in -Also note that these steps assume the transit agency is using Littlepay as their payment processor. Support for integration with [other payment processors](https://www.camobilitymarketplace.org/contracts/) may be added in the future. +Also note that these steps assume the transit agency is using Littlepay as their transit processor. Support for integration with [other transit processors](https://www.camobilitymarketplace.org/contracts/) may be added in the future. ## Configuration for development and testing @@ -32,7 +32,7 @@ For development and testing, only a Littlepay customer group is needed since the 1. Cal-ITP uses the transit agency's Littlepay merchant ID to create a customer group in the Littlepay QA environment for each type of eligibility (e.g. senior). 1. For each group that's created, a group ID will be returned and should be set as the `group_id` on a new `EligibilityType` in the Benefits database. (See [Configuration data](../data/) for more on loading the database.) 1. Cal-ITP creates a new `EligibilityVerifier` in the database for each supported eligibility type. This will require configuration for either [API](https://docs.calitp.org/eligibility-api/specification/)-based verification or verification through an [OAuth Open ID Connect provider](../oauth/) (e.g. sandbox Login.gov) -- either way, this resource should be meant for testing. -1. Cal-ITP creates a new `TransitAgency` in the database and associates it with the new `EligibilityType`s and `EligibilityVerifier`s as well as the existing Littlepay `PaymentProcessor`. +1. Cal-ITP creates a new `TransitAgency` in the database and associates it with the new `EligibilityType`s and `EligibilityVerifier`s as well as the existing Littlepay `TransitProcessor`. ## Configuration for production validation @@ -46,8 +46,8 @@ For production validation, both a customer group and discount product are needed 1. Cal-ITP associates the group with the product. 1. Cal-ITP creates a new `EligibilityType` **for testing purposes** in the Benefits database and sets the `group_id` to the ID of the newly-created group. 1. Cal-ITP creates a new `EligibilityVerifier` with configuration **for a testing environment** to ensure successful eligibility verification. (For example, use sandbox Login.gov instead of production Login.gov.) -1. Cal-ITP creates a new `PaymentProcessor` **for testing purposes** with configuration for production Littlepay. -1. Cal-ITP updates the existing `TransitAgency` (created [previously](#configuration-for-development-and-testing)) with associations to the eligibility types, verifiers, and payment processor that were just created for testing. +1. Cal-ITP creates a new `TransitProcessor` **for testing purposes** with configuration for production Littlepay. +1. Cal-ITP updates the existing `TransitAgency` (created [previously](#configuration-for-development-and-testing)) with associations to the eligibility types, verifiers, and transit processor that were just created for testing. At this point, Cal-ITP and transit agency staff can coordinate to do on-the-ground testing where a live card is tapped on a live payment validator. @@ -68,7 +68,7 @@ Once production validation is done, the transit agency can be added to the produ 1. Cal-ITP associates the group with the discount product created [previously during production validation](#configuration-for-production-validation). 1. Cal-ITP sets that group's ID as the `group_id` for a new `EligibilityType` in the Benefits database. 1. Cal-ITP creates a new `EligibilityVerifier` with configuration for the **production** eligibility verification system. -1. Cal-ITP creates a new `TransitAgency` in the database with proper associations to eligibility types, verifiers, and payment processor. +1. Cal-ITP creates a new `TransitAgency` in the database with proper associations to eligibility types, verifiers, and transit processor. ### Cleanup @@ -76,4 +76,4 @@ At this point, the customer group that was created in production Littlepay for t 1. Remove the association between the test customer group and discount product. 1. Delete the test customer group. -1. Remove temporary `EligibilityType`s, `EligibilityVerifier`s, and `PaymentProcessor` that were [created](#steps_1) in the Benefits test environment. +1. Remove temporary `EligibilityType`s, `EligibilityVerifier`s, and `TransitProcessor` that were [created](#steps_1) in the Benefits test environment. diff --git a/docs/development/application-logic.md b/docs/development/application-logic.md index 0d715bef7..7da08406c 100644 --- a/docs/development/application-logic.md +++ b/docs/development/application-logic.md @@ -233,7 +233,7 @@ flowchart LR ## Enrollment In this final phase, the user registers their contactless payment card with a concession group configured within the -payment processor (Littlepay). +transit processor (Littlepay). **_Cal-ITP Benefits never processes, transmits, nor stores the user's payment card details._** diff --git a/docs/enrollment-pathways/low-income.md b/docs/enrollment-pathways/low-income.md index ced5deada..b308eeaf9 100644 --- a/docs/enrollment-pathways/low-income.md +++ b/docs/enrollment-pathways/low-income.md @@ -62,7 +62,7 @@ Littlepay-->>Benefits: payment method enrollment confirmation 1. The IdG then passes the response from CDSS as low-income status = TRUE to the Cal-ITP Benefits app to indicate the person is eligible for a benefit. -1. The transit rider provides the debit or credit card details they use to pay for transit to Littlepay, the payment processor that facilitates transit fare collection. +1. The transit rider provides the debit or credit card details they use to pay for transit to Littlepay, the transit processor that facilitates transit fare collection. 1. The app registers the low-income benefit with the transit rider’s debit or credit card. diff --git a/docs/enrollment-pathways/veterans.md b/docs/enrollment-pathways/veterans.md index 441d452db..d854bb1e8 100644 --- a/docs/enrollment-pathways/veterans.md +++ b/docs/enrollment-pathways/veterans.md @@ -60,7 +60,7 @@ Littlepay-->>Benefits: payment method enrollment confirmation 5. The Cal-ITP Benefits app interfaces with the [California Department of Technology](https://cdt.ca.gov/) Identity Gateway (IdG) to verify benefit eligibility. The IdG requests the required personal information to verify veteran status from [Login.gov](https://Login.gov). 6. The IdG utilizes the [Veteran Confirmation API](https://developer.va.gov/explore/api/veteran-confirmation) provided by the US Department of Veterans Affairs to determine the rider’s veteran status. 7. The IdG passes the response from [VA.gov](https://VA.gov) as veteran status = TRUE to the Cal-ITP Benefits app to indicate the person is eligible for a benefit. -8. The transit rider provides the debit or credit card details they use to pay for transit to Littlepay, the payment processor that facilitates transit fare collection. +8. The transit rider provides the debit or credit card details they use to pay for transit to Littlepay, the transit processor that facilitates transit fare collection. 9. The app registers the veteran benefit with the transit rider’s debit or credit card. ## Alternative flows diff --git a/docs/product-and-design/use-cases/enrollment-use-cases.md b/docs/product-and-design/use-cases/enrollment-use-cases.md index 51213b409..18a807f1d 100644 --- a/docs/product-and-design/use-cases/enrollment-use-cases.md +++ b/docs/product-and-design/use-cases/enrollment-use-cases.md @@ -4,25 +4,25 @@ The use cases documented on this page focus on how the system is supposed to wor **Primary Actor**: Transit rider -**Systems**: Benefits app, payment processor +**Systems**: Benefits app, transit processor **Preconditions**: - Transit rider has confirmed their eligibility with the Benefits app - Transit rider has their contactless card information available -- Benefits app is able to contact the payment processor +- Benefits app is able to contact the transit processor **Trigger**: Transit rider initiates the enrollment phase **Basic flow**: 1. Transit rider enters their contactless card information -2. Benefits app passes that information to the payment processor to enroll the card -3. Payment processor successfully enrolls card +2. Benefits app passes that information to the transit processor to enroll the card +3. Transit processor successfully enrolls card **Alternate flows**: -- 3a. Payment processor returns with one of the following errors: card verification failed, token is invalid, or general server error +- 3a. Transit processor returns with one of the following errors: card verification failed, token is invalid, or general server error - 3a1. Transit rider chooses to retry, starting back at initiating the enrollment phase - 3b1. Transit rider leaves the Benefits app