refundDeal
Overview
The refundDeal command refunds funds to customers for transactions that have already been settled. This command automatically handles the complexity of refund vs cancellation logic based on the transaction's transmission status to Shva (Israel's payment processor).
Key Features:
Automatic fallback: Cancels non-transmitted transactions, refunds transmitted ones
Partial refunds: Support for amounts less than the original transaction
Installment flexibility: Customizable refund schedules for installment transactions
Multiple lookup methods: Find transactions using various identifiers
Use cases
Refund settled transactions: Process refunds for transactions that have been transmitted to Shva (see Refunds & Cancellations)
Partial refunds: Support for amounts less than the original transaction with flexible refund scheduling
Customer refund requests: Handle standard customer refund scenarios (recommended over
cancelDealin most cases)Installment transaction refunds: Refund installment transactions with customizable refund schedules (see Refunds & Cancellations)
Automatic fallback processing: Let the system determine whether to cancel or refund based on transmission status
Invoice-specific refunds: Use with
refundCgInvoicefor document-tied refunds
Request structure
For a comprehensive overview of the API request format and authentication, see API Request & Response General Structure.
Send a standard Hyp API request to your assigned server endpoint with the refundDeal command in the int_in parameter.
Server Endpoints: Use the server endpoint provided during merchant onboarding (e.g., https://your-hyp-environment-url/xpo/Relay).
The refundDeal command uses the following endpoint:
POST https://your-hyp-environment-url/xpo/Relay
Request parameters
user
string
Username for API authentication (body parameter)
password
string
Password for API authentication (body parameter)
int_in
string
XML payload containing the request data (body parameter)
XML payload structure
Required parameters
At least one of the following three parameters must be provided:
Optional parameters
Response structure
Successful response
A successful refundDeal response contains details of the new credit transaction:
Key Response Fields:
result:000indicates successful refundtranId: New transaction ID for the refund/cancellationtransactionType: Shows transaction type (Cancel for non-transmitted, Refund for transmitted)total: Amount that was refundedcgUid: Links back to original transaction
Error response
Error responses include specific error codes and messages. The response contains many fields, most of which will be empty for error cases. The key fields to focus on are result, message, userMessage, status, and statusText:
Code examples
Error codes
310
No debit deal matches the credit deal
Verify lookup parameters match an existing transaction
317
Missing required parameters
Ensure at least one lookup element is provided
320
Credit transaction already performed
Transaction already has a refund; cannot refund again
321
Credit amount differs from charge deal amount
Check refund amount against original transaction
324
Terminal not permitted to perform refund transactions
Contact support to enable refund permissions
332
Multiple transactions found
Use more specific lookup criteria or configure terminal settings
339
Refund credit type differs from original transaction
Ensure creditType matches original transaction
340
Refund number of payments differs from original transaction
Verify installment configuration
341
Refund amount differs from original transaction
Check amount validation settings
Related commands
doDeal- Process original payment transactions that can later be refundedcancelDeal- Cancel non-transmitted transactions (refundDeal automatically chooses this when appropriate)refundCgInvoice- Process invoice-specific refunds with document generationRequest Structure - General API request format
Refunds & Cancellations - Detailed guide on refund vs cancellation logic and installment handling
Last updated
Was this helpful?