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 cancelDeal in 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 refundCgInvoice for 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.

The refundDeal command uses the following endpoint:

POST https://your-hyp-environment-url/xpo/Relay

Request parameters

Parameter
Type
Description

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 ashraitEmvData element

  • Unique 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 cardExpiration

  • Provides 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 cardId is provided

  • Format 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: 000 indicates successful refund

  • tranId: New transaction ID for the refund/cancellation

  • transactionType: Shows transaction type (Cancel for non-transmitted, Refund for transmitted)

  • total: Amount that was refunded

  • cgUid: 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

Error Code
Description
Resolution

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

  • doDeal - Process original payment transactions that can later be refunded

  • cancelDeal - Cancel non-transmitted transactions (refundDeal automatically chooses this when appropriate)

  • refundCgInvoice - Process invoice-specific refunds with document generation

  • Request Structure - General API request format

  • Refunds & Cancellations - Detailed guide on refund vs cancellation logic and installment handling

Last updated

Was this helpful?