Spike : Investigation of Payment Refund Implementation

[OlgaPotiagalova]

See also #21376 and #21377.

This spike ticket is created to investigate the implementation of a payment refund mechanism in workflows where the application is not accepted.

The objective is to explore options for efficiently and securely issuing refunds

Scope

• [ ] Research existing refund options already utilized within the platform/applications in the modernized product
• [ ] Determine the ease of leveraging/integrating in to the product
• [ ] Consider factors such as security requirements, transaction fees, processing time

We might also need to assess regulatory and compliance requirements related to issuing refunds.

[severinbeauvais]

Hey @seeker25 , can we chat about this some time? We want to learn what's possible via a UI for processing refunds. Thx.

[OlgaPotiagalova]

Information from the Relationships team (John Lane):

Basic accounts can pay via: • Online Banking • Credit Card

Online Banking payment flow:

1. Client fills in a filing, and it is held in the draft/pending state
2. Client users their banking app to send BCROS a payment
3. The Pay system receives the payment and marks the filing as paid
4. The filing system receives the message that the payment is complete and it marks the filing as complete

^This would have to be done prior to staff looking at it if payment is to be done up front.

Credit Card payment flow:

1. Client fills in a filing
2. When they're done, they click the file and pay button
3. Filing app redirects the client to the Credit Card screen, client fills in card details
4. Redirect back to filing app when approved/declined

Premium accounts can pay via: • Pre-authorized debit (PAD) • BCOL Deposit account (aka drawdown account) • EFT (future)

For all of the above premium payment types, when the client clicks file and pay, the filing can be considered as paid.

Also John has confirmed that we are able to issue refund via our refund API

[severinbeauvais]

From Travis:

I think we built an ops only screen: https://dev.account.bcregistry.gov.bc.ca/pay/refund Partials aren't implemented for all You'll need these roles: allowedRoles: [Role.CreateCredits, Role.FasRefund] your staff account (s2beauva) has the role

it's the same route as the namerequest refund, I believe

this works for the following:

• PAD - credit
• Online Banking - credit
• Credit Card - refund
• BCOL - manual refund (*)
• EJV - reversal or refund

(*) it just triggers an email to the BCOL admin to refund an invoice number

[severinbeauvais]

Research existing refund options already utilized within the platform/applications in the modernized product

See above.

Also, Namerequest has a Refund option that users can click. We could trace that through and see how it works. Per Travis above, it's the same as described above.

Determine the ease of leveraging/integrating in to the product

Educated guess here, but it's likely a call to Pay API. Since Auth Web (aka Auth UI) already has that refund page, all integration is already present there (which is also where the Staff Reviews page will live).

One unknown is what data is needed when making the refund call. Probably the payment id but maybe more.

Consider factors such as security requirements, transaction fees, processing time

Refunds are already implemented for staff (and even users in specific scenarios), so security is unchanged. Note that, for the staff refund page, the staff need special account roles. ~We may want to create a new role for staff reviews...?~

Transaction fees and processing time will also be unchanged from the current implementation. We can ask John Lane for more info if needed.

We might also need to assess regulatory and compliance requirements related to issuing refunds.

Who can look into this? Sounds like a conversation with the business or Legal team.

[severinbeauvais]

@seeker25 Can you please share the existing endpoint and how it's called? Thanks!

[seeker25]

Full refund:

curl --location 'https://pay-api-test.apps.silver.devops.gov.bc.ca/api/v1/payment-requests/{invoiceId}/refunds' \
--header 'Content-Type: application/json' \
--header 'Authorization:xxx' \
--data '{"reason": "Refund request for ops ticket 3910"}'

Partial refund (not implemented for all payment methods, maybe just for CREDIT CARD), not released (only on DEV?) Partial refunds aren't possible to do on DRAWDOWN(BCOL) etc.. lots of issues and discussion for it.

curl --location 'https://pay-api-test.apps.silver.devops.gov.bc.ca/api/v1/payment-requests/{invoiceId}/refunds' \
--header 'Content-Type: application/json' \
--header 'Authorization:xxx' \
--data '{
    "reason": "Test test test xx",
    "refundRevenue": [
        {
            "paymentLineItemId": 9000000000,
            "refundAmount": 15.00,
            "refundType": "OTHER_FEES"
        },
        {
            "paymentLineItemId": 9000000000,
            "refundAmount": 1.50,
            "refundType": "SERVICE_FEE"
        }
    ]
}'

[severinbeauvais]

@seeker25 So we can use the first endpoint to fully refund any invoice that was paid in any manner? No need to send an email or anything?

[seeker25]

Yes as discussed above:

this works for the following:

PAD - credit Online Banking - credit Credit Card - refund BCOL - manual refund * EJV - reversal or refund

• it just triggers an email to the BCOL admin to refund an invoice number

[severinbeauvais]

Summary

It looks like we can automate refunds of rejected Continuation Applications by calling an existing endpoint. As it is an existing service, this should not change the current security requirements, transaction fees, processing time.

[seeker25]

Check the roles or permissions of the endpoint

[vikas-gov]

Olga/BA to review and close the ticket.