bcgov / bcgov/entity

MHR| Receipts and Proof of Payment Visibility for Fee-Based Searches and Registrations

Open
#32,188 0 comments 0 reactions 0 assignees View on GitHub
Assets
Dominant language
JavaScript
Stars
23
Forks
62
Avg merge
24m
Merged PRs (30d)
1

Description

### Problem Statement
Fee-based searches, registrations, and transmissions are performed by staff on behalf of clients, with payment taken at the time of transaction. The system produces search results or verification statements but does not generate a client-facing payment receipt.
Client-paid and internally generated outputs appear identical, with no indicator showing payment status or confirmation of successful payment. Receipts are inconsistently available, lack reliable links to client accounts, and provide limited detail. As a result, clients receive services without payment confirmation, and staff face difficulty providing proof of payment for refunds, audits, or evidence requests.
### Current State
Client‑paid searches, registrations, and transmissions are processed with payment taken upfront. A search result or verification statement is produced, while a client‑facing receipt is not generated. Paid and internal transactions appear identical, and confirmation of payment is not visible or easily traceable.
### Potential Risks
The absence of clear payment artefacts increases the risk of disputed charges, delayed or unsupported refunds, and weak audit evidence. Manual work is required to confirm payment, raising the likelihood of errors, inconsistent client responses, and reduced confidence in transaction integrity.
### Desired Outcome
Receipts should be generated for every fee-based transaction. Receipts link to the correct client account. Clients view receipts alongside results and statements. Receipts show clear context. Staff retrieve complete proof of payment without manual steps.
BA Notes:

- Client payments are taken through routing slips or BC Online numbers when staff perform searches, registrations, or transmissions for clients, yet a client‑facing receipt is not produced. Outputs look identical to internal work, and no visible payment indicator is embedded in the result.
- Without a receipt tied to the client account and the specific transaction, proof of payment is hard to provide during refunds, audits, or evidence requests. Staff must reconstruct payment history across systems, including legacy tools, which increases effort and error risk.
- Some receipts exist in backend services but are not reliably associated to the client account or transaction. Staff might see limited‑detail receipts, while clients see none. This gap weakens traceability and undermines client confidence in charges.
- Multiple paid transactions can be completed with no verifiable artefact for the client. Disputes are harder to resolve, refunds are delayed, and consistent service is not supported by the system.

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue names routing slips, BC Online numbers, backend services, and legacy tools, but no files, tests, or entry points. Start by mapping how paid searches, registrations, and transmissions are recorded and linked to client accounts; done means each fee-based transaction has a client-visible, traceable receipt with sufficient payment context for staff retrieval.

Written by the indexing model from the issue text.

Assessment

Domain
backend, payments
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.