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
Best Practice: Use refundDeal instead of cancelDeal when unsure about transmission status. The system automatically determines whether to cancel or refund based on the transaction state.
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:
tranId - Transaction ID
Type: String Required: At least one lookup parameter required Description: Unique transaction request ID for a specific transaction step
Example: 118372223
Usage Notes:
When provided, other lookup elements are ignored
Most specific identifier for a transaction step
Returned in response from the original transaction
cgUid - CG Identifier
Type: String Required: At least one lookup parameter required Description: CG identifier shared across related transactions (finds latest transaction state)
Example: 118372223
Usage Notes:
Links related transactions together
Useful for tracking transaction chains
Returned in response from the original transaction
orgUid - Original UID
Type: String Required: At least one lookup parameter required Description: Shva-assigned transaction ID (from inquire response)
Example:
Usage Notes:
Must be wrapped in
ashraitEmvDataelementUnique identifier from Shva payment processor
Used for direct transaction reference
Optional parameters
terminalNumber - Your merchant terminal identifier
Type: String Required: No Description: The unique terminal number assigned during merchant onboarding
Example: 0882819014
Usage Notes:
Must match your assigned terminal number
Used for transaction lookup and authorization
Available in your merchant dashboard
authNumber - Authorization Number
Type: String Required: No Description: Authorization number from credit card company
Example: 7823673
Usage Notes:
Can be included for additional validation
Helps ensure correct transaction matching
From the original transaction response
user - User Field
Type: String Required: No Description: Custom user identifier from original transaction
Example: customer123
Usage Notes:
Must match the value from the original transaction
Useful for merchant-specific tracking
Free-text field for merchant use
cardId - Card ID
Type: String
Required: No
Description: Card identifier (requires cardExpiration)
Example: 1092880571131111
Usage Notes:
Must be used together with
cardExpirationProvides additional transaction validation
From tokenization or original transaction
cardExpiration - Card Expiration
Type: String (MMYY format)
Required: No (required when using cardId)
Description: Card expiration date
Example: 0629
Usage Notes:
Required when
cardIdis providedFormat must be MMYY
Must match card's actual expiration
total - Refund amount in currency subunits
Type: String (numeric) Required: No Description: Amount to refund in cents/agorot (e.g., 4730 = $47.30)
Default: Full amount of original transaction
Example: 4730 (refunds $47.30)
Usage Notes:
Must be less than or equal to the original transaction amount
For partial refunds, the original transaction remains unchanged
Even partial refunds of non-transmitted transactions create credit transactions
creditType - Credit transaction type
Type: String Required: No Description: Type of credit to process
Default: RegularCredit
Valid Values: RegularCredit, other credit types as configured
Example: RegularCredit
Usage Notes:
Usually inherits from original transaction settings
Affects how credit appears on a customer statement
shiftId1, shiftId2, shiftId3 - Shift identifiers for transaction grouping
Type: String Required: No Description: Optional shift identifiers for transaction organization and reporting
Usage Notes:
Used for internal transaction grouping
Helpful for reconciliation and reporting
Must match the original transaction if provided
shiftTxnDate - Shift transaction date
Type: String Required: No Description: Date associated with shift for transaction grouping
Usage Notes:
Used alongside shift ID parameters
Helps locate transactions within specific time periods
transactionCode - Transaction processing code
Type: String Required: No Description: Specific transaction code for processing context
Usage Notes:
Usually inherits from the original transaction
Used for specialized transaction handling
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:
Note: Error responses include the full structure with many empty fields. Focus on the result, status, and message fields for error handling.
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?