refactor(core): inclusion of locker to store fingerprints

[prajjwalkumar17]

Type of Change

Refactoring the present blocklist flow and storing the fingerprint on our locker end for more security and efficiency.
More details are here in this issue.

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

After this change we will store the fingerprints on our locker in fingerprints table. No more storing anything related to fingerprints in our DB. There will be only one table usable left for blocklsit which will be blocklist (stores all the fingerprints blocked by a merchant with their type and metadata).
Previously we were generating the fingerprints on our application end itself after this change we will have the fingerprints generated by our locker.
Fingerprint is generated for each and every card payment. Moreover we are storing fingerprint in all the attempt tables.
Now vouching for the scenarios were there are more than one attempt associated with one intent in that case we are adding the successful attempt's fingerprint in intent.

Required DB changes

purpose: support for addition of fingerprint_id in payment_attempt table
Query:
ALTER TABLE payment_attempt ADD COLUMN IF NOT EXISTS fingerprint_id VARCHAR(64);

So how does the whole flow works:

1. Before confirmation of payment the payment instrument's fingerprint is cross-checked with the blocklist.
2. If it is present in blocklist the payment will be blocked (status as false).
3. This payment can be retried with another instrument and in case if succeeds the fingerprint will be added in intent.

Note: All successful attempts will have a fingerprint but intent's fingerprint will always be the successful attempt's fingerprint.

Other checkpoints under same hood

• Instead of generating the fingerprint in application add support for /cards/fingerprint API call with hash_key.
• whitelisting mentioned endpoint in proxy.
• Storing the fingerprint in payment attempt and payment intent table.
• Refactoring Block List checking using the fingerprint API.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

Generating fingerprints

-> Toggle the blocklist guard from merchant account being used using /blocklist/toggle?status=true. More about
toggling guard here.
-> We need to create a payment.
-> While trying to confirm the payment it will have the fingerprint_id in the response. This can be used to block the
instrument. If the payment was able to be captured the fingerprint will be stored in the intent table as well

Blocking fingerprints

Refer to the attached postman collection for the API contracts for the blocklist APIs(Description). Currently we support blocking three types of resources i.e. card numbers (payment intrument), card bin, and extended card bin.
blocklist_api_postman.zip

For Card Bin and Extended Card Bin :-
1. Setup a Merchant Account and any Connector account
2. Make a payment with a certain card (ensure it succeeds)
3. Block the card's card bin or extended card bin
4. Try the payment again (should fail this time with an API response saying that the payment was blocked)

For Payment Instrument :-
1. Repeat steps 1 and 2 of previous section
2. In the payment confirm response, there will be an additional field called "fingerprint". This is the fingerprint id that can be used to block a particular payment method. Use this to block the card.
3. Try the payment again (should fail)

The respected curls are mentioned in the issue.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible
• I added a CHANGELOG entry if applicable

[NishantJoshi00]

LGTM,
just a question, can we also plan on deprecating the fingerprint id column in payment intent

[prajjwalkumar17]

LGTM,
just a question, can we also plan on deprecating the fingerprint id column in payment intent

Well we are adding the fingerprint of the successful attempt in our intent so we are not going to depreciate it. Intents's fingerprint Will be used by dashboard to flag payments.
Btw why do you suggest for depreciation?