Project

General

Profile

Actions

Task #823

open

Epic #786: Square Payment Gateway Integration

Feature #821: Transactions & Reconciliation

Store Payment Response

Added by Redmine Admin about 2 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Start date:
04/22/2026
Due date:
% Done:

0%

Estimated time:

Description

Persist full or partial Square API response for each transaction. This helps in debugging and reconciliation.

Actions #1

Updated by Deeksha Singh about 1 month ago

Module: Store Payment Response (Square)

TC_ID_RESPONSE_01
Title: Verify full payment response is stored after successful transaction
Preconditions: Payment successful
Steps:

Perform payment
Check database
Test Data: Successful payment response
Expected Result: Full response is stored correctly

TC_ID_RESPONSE_02
Title: Verify partial response is stored for failed transaction
Preconditions: Payment fails
Steps:

Trigger failed payment
Check DB
Test Data: Error response
Expected Result: Partial response stored with error details

TC_ID_RESPONSE_03
Title: Verify response is linked to correct transaction
Preconditions: Transaction exists
Steps:

Perform payment
Check DB mapping
Test Data: payment_id
Expected Result: Response mapped to correct transaction record

TC_ID_RESPONSE_04
Title: Verify important fields are stored from response
Preconditions: Payment processed
Steps:

Check stored response
Test Data: payment_id, status, amount
Expected Result: Key fields stored correctly

TC_ID_RESPONSE_05
Title: Verify response is stored in structured format (JSON/text)
Preconditions: Payment completed
Steps:

Check DB
Test Data: API response
Expected Result: Response stored in readable structured format

TC_ID_RESPONSE_06
Title: Verify handling of large response data
Preconditions: Large response payload
Steps:

Perform payment
Check DB
Test Data: Full Square API response
Expected Result: Response stored without truncation

TC_ID_RESPONSE_07
Title: Verify sensitive data is not stored unnecessarily
Preconditions: Payment completed
Steps:

Inspect stored response
Test Data: API response
Expected Result: No sensitive data (like card details) stored

TC_ID_RESPONSE_08
Title: Verify error handling when response storage fails
Preconditions: Simulate DB failure
Steps:

Perform payment
Test Data: DB error scenario
Expected Result: Error handled properly, no system crash

TC_ID_RESPONSE_09
Title: Verify response is stored for each transaction uniquely
Preconditions: Multiple payments
Steps:

Perform multiple payments
Check DB
Test Data: Multiple responses
Expected Result: Each transaction has its own response stored

TC_ID_RESPONSE_10
Title: Verify logging of response storage activity
Preconditions: Logging enabled
Steps:

Perform payment
Check logs
Test Data: Payment response
Expected Result: Storage activity logged without exposing sensitive data

Actions

Also available in: Atom PDF