| Description | What triggered the refund or void. |
| Context | Extra detail that does not change the reason code. |
| Recommendations | Merchant follow-up after the refund or void. |
| Customer request Manual refund from Hub after the customer asks for a return. |
| Review Review flagged transactions and refund patterns. |
| Merchant action The merchant decides whether to refund after an issuer request. |
| Automatic Solidgate issues the refund without a merchant request. |
| Contact support Requires Solidgate team intervention. |
| Developer action Update order status or void handling after a scheme reversal. |
Both void and refund operations come with associated reason codes. Void operations cancel transactions before finalization, while refund operations return funds to customers after transactions are complete.
These codes help analyze return processes and automate actions or events based on refund or void reasons.Customer request
0021 Solidgate – request by user
This code applies to any manual refunds initiated through the Solidgate Hub .
It indicates a refund made per the customer’s request and does not necessarily imply an issue.
Refund Customer request Monitor the frequency of these refunds to identify any patterns or common reasons that may be addressed to improve customer satisfaction.Fraud and risk
0022 Solidgate – issuer fraud notification
This code is used when the issuer directly reports a fraudulent charge to Solidgate. Support team may initiate a refund after contacting the merchant.
It signifies a flagged transaction due to fraudulent activity.
Refund Contact support Maintain close communication with Solidgate to understand the nature of these fraudulent activities. Consider implementing additional security measures if these incidents are frequent.0023 Solidgate – risk department
Result of fraud detection. The customer can ask for a refund for the transaction.
Indicates transactions flagged for potential fraud.
Refund Review Regularly review transactions flagged by the Risk Department to understand if legitimate transactions are being affected.0027 Solidgate – antifraud
This code is used for automatic refund actions triggered by the antifraud system.
Indicates automated fraud detection measures.
Refund Automatic Consistently review and update your fraud prevention settings to keep pace with emerging fraud patterns. Contact the Solidgate team to coordinate and improve these settings.Prevention and retrieval
0024 Solidgate – retrieval request
When the issuer posts a retrieval request, the merchant may choose to refund the transaction.
Signifies a formal request by the issuer for transaction documentation.
Refund Merchant action If retrieval requests are frequent, review your transaction descriptors and customer communication to reduce misunderstandings that could lead to retrieval requests.0025 Solidgate – prevention alert
Refunds are automatically issued when Solidgate receives a prevention alert.
Previously, the following refund codes 0016, 0017, 0018, 0019 were used.
Refund Automatic Work closely with Solidgate to understand the triggers for these prevention alerts and consider tweaking your security settings or customer verification processes to minimize them.System and scheme
0026 Solidgate – system error
This code is used rarely, only in case of technical problems between Solidgate, providers, and payment networks.
Indicates a system malfunction or technical issue.
Refund Contact support Contact the Solidgate team immediately to report any system errors for troubleshooting. Review any commonalities in these errors to preemptively address technical vulnerabilities.0028 Solidgate – expired authorization
After the authorization expires, Solidgate may issue a void using this code.
Indicates an expired authorization for a transaction.
Void Contact support Monitor the time between authorization and transaction completion to minimize instances of expired authorizations. Contact the Solidgate team to coordinate and potentially extend authorization periods if necessary.0029 Solidgate – reversed by schemes
This rule applies when card schemes cannot confirm a payment authorization during the clearing process.
In such cases, to comply with card scheme requirements, the Acquirer/PSP must reverse (void) the original authorization transaction to release the blocked funds in the customer’s account.
Track card order Webhook for further investigation.
0001-0020 Deprecated
| Code | Name |
|---|---|
| 0001 | Request by Support |
| 0002 | Fraud – PSP |
| 0003 | Fraud – SP Antifraud |
| 0004 | Fraud – SP Antifraud |
| 0005 | Fraud – MaxMind |
| 0006 | Fraud – Threatmetrix |
| 0007 | Fraud – Manual check |
| 0008 | Potential Chargeback – Retrieval Request |
| 0009 | Potential Chargeback – Refund after Chargeback |
| 0010 | System Error – Product |
| 0011 | System Error – SignedPay |
| 0012 | System Error – PSP |
| 0013 | Ethoca alert – Fraud |
| 0014 | Ethoca alert – Friendly Fraud |
| 0015 | Ethoca alert – Potential Chargeback |
| 0016 | Verifi alert – Fraud |
| 0017 | Verifi alert – Friendly Fraud |
| 0018 | Verifi alert – Potential Chargeback |
| 0019 | VMPI Alert |
| 0020 | Mismatch status (Decline – Approved) |