Skip to main content
Yuno provides merchants with the ability to retry capture and refund transactions that have encountered errors or been declined by the provider. This feature aims to enhance transaction success rates and improve the user experience. By setting the simplified_mode field to true in capture and refund requests, Yuno will automatically retry failed transactions up to seven times within a 96-hour period. The system handles the following scenarios during the retry process:

​
Capture transactions

Capture transactions can encounter various statuses during and after the retry process. The table below details these statuses:
Payment while retry is ongoingPayment after successful retriesPayment after failed retries
SUCCEEDED / CAPTURE_RETRY_IN_PROCESSSUCCEEDED / CAPTURED or PARTIALLY_CAPTURED depending on the amount.SUCCEEDED / CAPTURE_RETRY_PROCESS_FAILED

​
Refund transactions

Refund transactions also have specific statuses during and after the retry process. The table below outlines these statuses:
Payment while retry is ongoingPayment after successful retriesPayment after failed retries
SUCCEEDED / REFUND_RETRY_IN_PROCESSREFUNDED / REFUNDED or SUCCEEDED / PARTIALLY_REFUNDED depending on the amount.SUCCEEDED / APPROVED

​
Benefits

This feature provides several advantages:
  • Improved transaction success rates: Automatic retries enhance the likelihood of successful transaction completions, leading to higher approval rates and increased revenue.
  • Enhanced user experience: By automatically retrying failed transactions, user friction is reduced, improving overall customer satisfaction and retention.
  • Operational efficiency: Automating retry attempts optimizes time and resources by minimizing manual intervention for failed transactions, allowing teams to focus on strategic tasks.

​
Retry scheme

The retry scheme is crafted to maximize transaction success by scheduling retries at strategic intervals. The table below describes the intervals between each retry. Note that each retry is scheduled based on the timing of the last attempt, meaning the time between retries is cumulative:
EventDeadline after the first try
First try-
Second try5 minutes
Third try50 minutes
Fourth try6 hours
Fifth try24 hours
Sixth try48 hours
Seventh try96 hours
This table illustrates that each retry is performed based on the time elapsed since the previous attempt, not the initial attempt. For example, the fourth retry occurs 6 hours after the third retry rather than 6 hours after the first attempt. The entire schedule spans 7 days and 7 hours in total.

​
Examples

Below are examples of capture authorization and refund requests using the simplified mode.
Capture
curl --request POST \
     --url https://api-sandbox.y.uno/v1/payments/id/transactions/transaction_id/capture \
     --header 'X-Idempotency-Key: <Your X-Idempotency-Key>' \
     --header 'accept: application/json' \
     --header 'charset: utf-8' \
     --header 'content-type: application/json' \
     --header 'private-secret-key: <Your private-secret-key>' \
     --header 'public-api-key: <Your public-api-key>' \
     --data '
{
  "amount": {
    "currency": "JPY",
    "value": 300
  },
  "simplified_mode": true,
  "description": "Confirmed",
  "reason": "PRODUCT_CONFIRMED",
  "merchant_reference": "AAB01-432245"
}
'
Refund
curl --request POST \
     --url https://api-sandbox.y.uno/v1/payments/id/transactions/transaction_id/refund \
     --header 'X-Idempotency-Key: <Your X-Idempotency-Key>' \
     --header 'accept: application/json' \
     --header 'charset: utf-8' \
     --header 'content-type: application/json' \
     --header 'private-secret-key: <Your private-secret-key>' \
     --header 'public-api-key: <Your public-api-key>' \
     --data '
{
  "simplified_mode": true,
  "description": "Refund",
  "reason": "REQUESTED_BY_CUSTOMER",
  "merchant_reference": "AAB01-432245"
}
'