Ingenico Direct Support Site

Results for

icon-search-large No search results yet
Enter your search query above

Hosted Checkout statuses

The hostedCheckout API can return two statuses and two status categories, each has their own purpose to aid you to code defensively to future new statuses.

HostedCheckout
status paymentOutput
paymentStatusCategory payment
statusOutput
statusCategory
CANCELLED_BY_CONSUMER N/A N/A N/A
CLIENT_NOT_ELIGIBLE_FOR_SELECTED_PAYMENT_PRODUCT N/A N/A N/A
IN_PROGRESS N/A N/A N/A
PAYMENT_CREATED REJECTED CREATED CREATED
CANCELLED UNSUCCESSFUL
REJECTED
REJECTED_CAPTURE
STATUS_UNKNOWN REDIRECTED PENDING_PAYMENT
SUCCESSFUL PENDING_PAYMENT
PENDING_COMPLETION PENDING_MERCHANT
PENDING_CAPTURE
AUTHORIZATION_REQUESTED PENDING_CONNECT_OR_3RD_PARTY
CAPTURE_REQUESTED
CAPTURED COMPLETED
CHARGEBACKED REVERSED
REVERSED

hostedCheckout.status

This is the high–level status of the hosted checkout itself. You use this status to check if a hostedcheckout has resulted in a payment attempt. Possible values are:

hostedCheckout.status description
CANCELLED_BY_CONSUMER If a consumer cancels the payment on the payment product detail page of the Hosted Checkout pages, the status will change to IN_PROGRESS. Since we understand you want to be aware of a consumer cancelling the payment on the page we host for you, you can choose to receive the status CANCELLED_BY_CONSUMER instead of the status IN_PROGRESS. In order to receive the status CANCELLED_BY_CONSUMER, you need to have the returnCancelState flagenabled in the Create hosted checkout call
IN_PROGRESS The checkout is still in progress and has not finished yet
PAYMENT_CREATED A payment has been created
Please check the status of the payment to verify if a successful payment has been created. In case this is not the case please note that depending on your setup it is possible that the consumer may create more than one payment attempt during one hostedCheckout session.

hostedCheckout.paymentOutput.paymentStatusCategory

This is the high level status category for a hosted checkout that allows you to determine if the payment that was created was successful or not. In the case of a REDIRECTED payment, we don’t know the final state yet, so in that case the status is STATUS_UNKNOWN. Possible values are (please note that refund, payout and capture statuses are not listed as these objects can't be created during a hosted checkout):

hostedCheckout.paymentOutput.paymentStatusCategory description
REJECTED The payment has been rejected or is in such a state that it will never become successful.
SUCCESSFUL The payment was successful.
STATUS_UNKNOWN The status of the payment is unknown at this moment.

Payment statuses

The payment statuses are returned as part of the hostedCheckout response, but they are identical to the elements that are returned for a payment processed through a Create payment.

payment
statusOutput
statusCategory
CREATED CREATED
REJECTED UNSUCCESSFUL
REJECTED_CAPTURE
REDIRECTED PENDING_PAYMENT
PENDING_PAYMENT
PENDING_APPROVAL PENDING_MERCHANT
PENDING_COMPLETION
PENDING_CAPTURE
AUTHORIZATION_REQUESTED PENDING_CONNECT_OR_3RD_PARTY
CAPTURE_REQUESTED
CAPTURED COMPLETED
REVERSED REVERSED

paymentOutput.payment.status

This is the actual status of the payment object that was created during the hosted checkout in a human-readable form. This is the most detailed status of a payment object. The status a payment can reach depends greatly on the payment product used by the consumer to complete the payment, and in some cases also on your configuration and/or flags submitted in the Create payment or the Create HostedCheckout API call. It is possible that due to enhancements or new payment products new statuses are added. Your code should be able to gracefully handle those cases.Possible values are:

paymentOutput.payment.status description
CREATED The transaction has been created. This is the initial state once a new payment is created.
REDIRECTED The consumer has been redirected to a 3rd party to complete the authentication/payment
PENDING_PAYMENT Instructions have been provided and we are now waiting for the money to come in
PENDING_COMPLETION The transaction needs to be completed. Transactions in this state can be completed only once.
PENDING_CAPTURE The transaction is awaiting approval from you to proceed with the (partial) capturing of the funds. Transactions in this state can be captured in partial captures.
REJECTED The transaction has been rejected
AUTHORIZATION_REQUESTED We have requested an authorization against an asynchronous system and is awaiting its response
CAPTURE_REQUESTED The transaction is in the queue to be captured
CAPTURED The transaction has been captured and we have received online confirmation
CANCELLED You have cancelled the transaction
REJECTED_CAPTURE We or one of our downstream acquirers/providers have rejected the capture request
REVERSED The transaction has been reversed

paymentOutput.payment.statusOutput.statusCategory

This is the category of the payment status of the payment object that was created. In the state transition diagrams that can be seen on the payment product pages these are the names of the bands that the status falls in. This allows you to build logic that will not break when we add a new status to a category. It is less likely that we will add new categories vs statuses. In case your system encounters a status that it is unfamiliar with you should have logic that will instead use this field as a fall-back.

Possible values are:

paymentOutput.payment.statusOutput.statusCategory description
CREATED The transaction has been created. This is the initial state once a new payment, payout or refund is created. No action from you is required at this state.
PENDING_PAYMENT The payment is waiting on consumer action. No action from you is required at this state.
PENDING_MERCHANT The transaction is awaiting your approval to proceed with the payment, payout or refund.
PENDING_CONNECT_OR_3RD_PARTY The transaction is in the queue to be processed and no action from you is required at this stage.
COMPLETED The transaction has completed. No action from you is required at this state.
REVERSED The transaction has been reversed. You might want to dispute the chargeback.
UNSUCCESSFUL The transaction has been rejected or is in such a state that it will never become successful. No action from you is required at this state.

The response also contains a statusCode. This field holds the status as returned by the Ingenico platform.

Refund statuses

The refund statuses apply to all refund objects that have been created using the Refund API.

refund
statusOutput
statusCategory
CREATED CREATED
CANCELLED UNSUCCESSFUL
REJECTED
REFUND_REQUESTED PENDING_CONNECT_OR_3RD_PARTY
REFUNDED REFUNDED

refundResponse.status

This is the actual status of the refund object that was created in a human-readable form. This is the most detailed status of a refund object. The status a refund can reach depends greatly on the payment product used by the consumer for the original payment and in some cases also on your configuration and/or flags submitted in the Create refund API. It is possible that due to enhancements or new payment products new statuses are added. Your code should be able to gracefully handle those cases.

Possible values are:

REJECTED The refund has been rejected
REFUND_REQUESTED The transaction is in the queue to be refunded
CANCELLED You have cancelled the refund
REFUNDED We have successfully refunded the consumer

refundResponse.statusOutput.statusCategory

This is the category of the refund status of the refund object that was created. In the state transition diagrams that can be seen on the payment product pages these are the names of the bands that the status falls in. This allows you to build logic that will not break when we add a new status to a category. It is less likely that we will add new categories vs statuses. In case your system encounters a status that it is unfamiliar with you should have logic that will instead use this field as a fall-back.

Possible values are:

refundResponse.statusOutput.statusCategory description
CREATED The transaction has been created. This is the initial state once a new payment, payout or refund is created. No action from you is required at this state.
PENDING_CONNECT_OR_3RD_PARTY The transaction is in the queue to be processed and no action from you is required at this stage.
REFUNDED The transaction has been refunded. No action from you is required at this state.
UNSUCCESSFUL The transaction has been rejected or is in such a state that it will never become successful. No action from you is required at this state.

The response also contains a statusCode. This field holds the status as returned by the Ingenico platform.

Capture statuses

The capture statuses apply to all capture objects that have been created using the Capture API.

captures
statusOutput
statusCategory
CANCELLED UNSUCCESSFUL
REJECTED_CAPTURE
REVERSED
CAPTURE_REQUESTED PENDING_CONNECT_OR_3RD_PARTY
CAPTURED COMPLETED

captureResponse.status

This is the actual status of the refund object that was created in a human-readable form. This is the most detailed status of a refund object. The status a refund can reach depends greatly on the payment product used by the consumer for the original payment and in some cases also on your configuration and/or flags submitted in the Create refund API. It is possible that due to enhancements or new payment products new statuses are added. Your code should be able to gracefully handle thosecases.

Possible values are:

captureResponse.status description
REJECTED_CAPTURE The capture has been rejected
REVERSED The capture has been reversed
CAPTURE_REQUESTED The capture is in the queue to be captured
CAPTURED The transaction has been captured and we have received online confirmation
CANCELLED You have cancelled the capture

captureResponse.statusOutput.statusCategory

This is the category of the capture status of the capture object that was created. In the state transition diagrams that can be seen on the payment product pages these are the names of the bands that the status falls in. This allows you to build logic that will not break when we add a new status to a category. It is less likely that we will add new categories vs statuses. In case your system encounters a status that it is unfamiliar with you should have logic that will instead use this field as a fall-back.

Possible values are:

captureResponse.statusOutput.statusCategory description
PENDING_CONNECT_OR_3RD_PARTY The capture is in the queue to be processed and no action from you is required at this stage.
COMPLETED The capture has completed. No action from you is required at this state.
UNSUCCESSFUL The capture has been rejected or is in such a state that it will never become successful. No action from you is required at this state.

The response also contains a statusCode. This field holds the status as returned by the Ingenico platform