Abin ToppoandClaude Opus 5.5
f960a119e8
- Positive Pay on the 12 Oct /pps contract (account number, not account ID): OTP enrollment, cheque submit, saved cheques, detail and stop payment. Full flow passed on the phone against mobile-banking-backend.lincpay. - Statement & Mini Statement guide v1.0 (14 Oct): mini statement JSON on Home and the Statement screen; dated PDF export with the password rule. - Onboarding slides and splash screen, Inter font, shared Icon and TypewriterText components, nearby branches via OpenStreetMap. - Every feature switched on; the 14 Oct switch set is kept in featureConfig.stage-2026-10-14.ts. Loans run on demo data until the backend has /loans routes. - npm run android wraps run-android for shells spawned from VS Code. - OpenProject work packages updated to 14-10-2026 status, with screenshots of Positive Pay, statement, loans and cards. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6.9 KiB
OpenProject sprint: Positive Pay development
Create the SPRINT work package first, then each TASK below as its child. In the work package table, right-click the sprint row and choose Create new child.
For every work package, set:
- Assignee: Abin Toppo
- Client bank name: Apna Sahakari Bank Ltd.
- Status: Developed
Copy the Subject into the subject field and the text under Description into the description field.
SPRINT: Positive Pay development
- Subject: Sprint: Positive Pay development
- Parent: FEATURE 6: Cheque services (add a "Relates to" relation to Task 6.3 Positive Pay)
- Start date: 09-10-2026 · Finish date: 13-10-2026
- Status: Developed · Priority: High
Description
Positive Pay built in the mobile app on the backend's new Positive Pay API (/pps). The customer turns Positive Pay on for an account with an OTP, registers each cheque with the bank before handing it over, sees their saved cheques, and can stop a submitted cheque.
The app follows the backend team's Positive Pay integration guide (12-10-2026, re-checked against the 13-10-2026 version). Accounts are identified by account number; the app never sends an account ID. The live API at mobile-banking-backend.lincpay was checked against the guide on 13-10-2026 and matches it.
Endpoints: /pps/enrollment/accounts, /pps/enrollment/initiate, /pps/enrollment/verify-otp, /pps/enrollment/resend-otp, /pps/cheques (GET, POST), /pps/cheques/{chequeId}, /pps/cheques/{chequeId}/stop-payment
Tasks in this sprint:
- Positive Pay API connection
- Turn on Positive Pay with OTP
- Register a cheque
- Saved cheques list
- Cheque detail and stop payment
- Error handling
- Stop payment in the Services hub
TASK 1: Positive Pay API connection
- Subject: Positive Pay API connection
Description
Connected the app to all 8 Positive Pay endpoints.
- Every request carries the existing session token. There is no separate Positive Pay login.
- Accounts are sent by account number, as text, so leading zeros are kept. Moved from account ID to account number on 12-10-2026, when the backend changed its API.
- Every reply is checked before it is used. A reply the app cannot read is treated as an unknown outcome, never as success.
- Submitting a cheque and stopping one wait up to 60 seconds, because both go through to the bank.
- The cheque list and detail always read fresh from the backend when a screen opens.
TASK 2: Turn on Positive Pay with OTP
- Subject: Turn on Positive Pay with OTP
Description
The customer picks an account and the app checks whether Positive Pay is already on. If it is off, the customer turns it on with an OTP.
- The OTP goes to the registered mobile number from the customer's profile, shown masked on screen.
- The expiry and resend countdowns use the seconds the backend returns, not fixed values.
- Resend is disabled until its countdown ends. The app stops offering resend when the backend's limit is reached.
- A wrong code can be corrected. An expired code, or too many wrong ones, ends the OTP session, and the customer can start again.
- If the answer to verify is lost, the app first checks whether Positive Pay turned on, before asking the customer to do anything again.
- The OTP and its request ID stay on the screen only. They are not stored and not written to the logs.
- Switching accounts during the OTP drops that OTP session.
Endpoints: /pps/enrollment/accounts, /pps/enrollment/initiate, /pps/enrollment/verify-otp, /pps/enrollment/resend-otp
TASK 3: Register a cheque
- Subject: Register a cheque under Positive Pay
Description
Form for one cheque on an account with Positive Pay on: cheque number, cheque date, amount and payee name. The customer checks the details on a confirmation screen before they are sent.
- Cheque number: exactly 6 digits, kept as text so 000123 stays 000123.
- Cheque date: from a date picker. Post-dated cheques are allowed, up to one year ahead.
- Amount: at least 0.01, up to 2 decimal places. It is sent exactly as entered, with no rounding.
- Payee name: up to 200 characters. Spaces at the start and end are removed.
- Each submission gets a request ID. The ID is kept if the customer tries again with the same details, even after leaving the screen, so a cheque cannot be registered twice.
- Submitted is shown only when the bank confirms. If the outcome is unknown, the app says so, looks for the cheque in the saved list, and links to it.
- A double tap sends only one request.
Endpoint: /pps/cheques (POST)
TASK 4: Saved cheques list
- Subject: Positive Pay saved cheques list
Description
List of every cheque the customer has registered, across all their accounts, newest first.
- 20 cheques per page. The next page loads on scroll, and pull to refresh reloads the list.
- Each row shows the cheque number, the masked account, the payee, the amount and the status: Submitted, Canceled, Failed or Processing.
- A status the app does not know is still shown, in neutral styling.
- The empty state links to registering a cheque.
Endpoint: /pps/cheques (GET)
TASK 5: Cheque detail and stop payment
- Subject: Positive Pay cheque detail and stop payment
Description
The detail screen shows one saved cheque: amount, status, cheque number and date, payee, masked account, bank reference, and the registered, submitted and canceled times.
- Stop payment is offered only on a Submitted cheque, and the customer must confirm it first.
- The stop has its own request ID, separate from the submission's.
- The cheque changes to Canceled only after the bank confirms the stop. A failed or unanswered stop leaves it Submitted.
- After a failed stop, the customer can try again only after reading why it failed.
- Failed and Processing cheques show what the status means and that the cheque must not be registered again.
Endpoints: /pps/cheques/{chequeId}, /pps/cheques/{chequeId}/stop-payment
TASK 6: Error handling
- Subject: Positive Pay error handling
Description
Every error code in the backend's Positive Pay guide has its own message and its own action in the app. The app decides from the error code, never from the message text.
- An unknown code, a timeout or a lost connection on a submit or a stop is treated as "outcome unknown", never as a failure the customer could fix by entering the cheque again.
- The app never resends a submission or a stop on its own.
- If the session has ended, the customer is signed out.
- Unit tests cover the error rules, the amount format and the cheque rules (51 tests passing).
TASK 7: Stop payment in the Services hub
- Subject: Stop payment through Positive Pay in the Services hub
Description
Stop payment in the Services hub now lists the customer's Positive Pay cheques and stops them through the Positive Pay API. The customer picks a cheque instead of typing an account and cheque number. This replaces /check/verify and /check/stop-payment (Task 6.2).