Skip to content

Error Handling

In this guide

The ErrorCode values the SDK reports, what each one means, what to do about it, and a recommended handling pattern.

Handle errors by using PaymentError.code for program logic and PaymentError.message for display or support context.

Error Codes

NOT_INITIALIZED
DigetPay.initialize() was not called. Do: Fix app startup configuration.
NETWORK_ERROR
Request could not reach DigetPay. Do: Ask the user to check connectivity and retry.
INVALID_API_KEY
The configured API key is invalid. Do: Check merchant credentials.
PAYMENT_DECLINED
The gateway declined the payment. Do: Ask the user to try another method.
SESSION_EXPIRED
Checkout or 3-D Secure session expired. Do: Start a new payment session.
UNKNOWN
Unexpected failure. Do: Log details and contact support if it repeats.

Branch on the enum, not the message

Messages can change; ErrorCode values are stable. Always switch on code for logic and reserve message for display.

override fun onFailure(error: PaymentError) {
    when (error.code) {
        ErrorCode.NOT_INITIALIZED -> showSetupError()
        ErrorCode.NETWORK_ERROR -> showRetryMessage()
        ErrorCode.PAYMENT_DECLINED -> showDeclinedMessage()
        else -> showGenericPaymentError(error.message)
    }
}

Production Checklist

Before you go live

  • Show friendly, user-facing messages.
  • Log code and details for diagnostics.
  • Retry only idempotent reads, such as status checks.
  • Reconcile important orders through status checks or backend webhooks.

Never log card data

Do not log full card numbers, CVV, or any raw card fields — in Logcat, crash reports, or analytics. This is a hard PCI DSS requirement.