Understanding the payment lifecycle helps you track money movement, diagnose failures faster, and explain outcomes to customers.

Solidgate order logs are stored for the last 60 days. Contact Solidgate support if you need information about older data.

An order is the customer’s purchase request, and a transaction is a single payment action within that order.

Each stage represents a step in payment processing, from initiation and verification to a final state. The final state can be a completed settlement in which funds are captured, a failure to reserve funds, or a successful void in which reserved funds are released.

Solidgate offers

  • reporting solution for detailed transaction data, order status tracking, and actionable insights into customer behavior
  • payments analytics with insights into gross volume, approval rates, declines, and transaction risks to optimize payment processes and improve customer experience

Order status

Value Final state Description
processing No An order enters this state when payment is first attempted and stays here until payment is captured.
3ds_verify No This state is for orders undergoing 3D Secure verification, triggered by a payment request with a 3D parameter or additional verification by Solidgate or the issuing bank.
auth_ok No Indicates successful reservation of funds for the transaction.
auth_failed Yes This state indicates a failure in reserving funds.
void_ok Yes The reservation of funds has been voided.
settle_ok Yes Reserved funds have been successfully captured.
partial_settled Yes A portion of the funds has been captured.
refunded Yes The order funds were transferred back to the cardholder.

Final state reflects the outcome of payment processing at that moment. The payment lifecycle may continue with refunds, which can update the order status.

Non-final states are temporary and change automatically.


Transaction status

Value Description
processing The transaction is currently undergoing processing.
verify The transaction is undergoing 3D Secure verification, and the customer should be redirected to the ACS URL provided to finalize the payment.
success The transaction has been successfully processed.
fail The transaction has been rejected. Refer to the error code for additional information.

Transaction type

Value Description
recurring-auth The operation of reserving funds using a token.
refund The operation of transferring funds back to the cardholder.
resign-auth The operation of reserving funds using a token and CVV.
auth The operation of reserving funds.
settle The operation of settling reserved funds.
void The operation of cancelling a reserved fund.
apple-pay The charge via Apple Pay.
google-pay The charge via Google Pay.

Payment type

Value Description
1-click CIT Customer-initiated transaction.
recurring MIT Subscription-based merchant-initiated transaction.
retry MIT Reattempt of a merchant-initiated transaction.
installment MIT Merchant-initiated debit method for credits and installments.
rebill MIT An unscheduled withdrawal by a merchant is triggered under certain conditions.
moto CIT Mail Order/Telephone Order transaction (MOTO) is a type of card-not-present (CNP) payment where customers provide their payment details to the merchant through email, post, fax, or telephone.

Payment gets declined if

  • card_cvv is provided with the moto payment type
  • either card_cvv nor payment_type is provided

Highly recommended to specify the scheme_transaction_id with stored card details, taken from the first PSP transaction, for transactions such as recurring , retry , installment , or rebill as it proves the linkage between MITs and the initial CIT by referencing the scheme_transaction_id value from that CIT in all subsequent MITs.

1-click

Payment type 1-click can trigger 3D Secure (3DS) force3ds true verification, which requires additional authentication by displaying the bank’s ACS URL.

Also, you should know that Apple Pay and Google Pay do not support 1-click payment type according to Payment System Rules, so it is recommended redisplaying payment buttons for upsells on the checkout screen.


Webhooks

Via API Webhooks notify merchants in real-time about updated card order Webhook changes, such as refund , void , and settle types. Set up and manage events API by creating endpoints, listing them, updating, or deleting.

Receive notifications when created network token Webhook or updated network token Webhook by Visa or Mastercard. Real-time alerts for received dispute Webhook , received prevention alert Webhook , and received fraud alert Webhook allow to manage risk effectively.

Track updates

In payment processing, tracking and managing key data is essential for ensuring smooth and secure transactions.

American card address data

After the payment data is processed, if the bin of an American card is provided, you should expect the returned address parameters to contain American address data. This includes details such as the country, city, state, and zip code associated with the card’s BIN.

If the data is bound by strict logic, consider including this information in the order_metadata object to ensure that all necessary billing details are provided and facilitate further processing.

Transaction tracking identifiers

Tracking identifiers like Payment Account Reference (PAR), Acquirer Reference Number (ARN), and Retrieval Reference Number (RRN) are essential for enhancing transaction visibility, streamlining dispute resolution, and improving fraud detection.

PAR payment_account_reference provides a consistent reference for tracking customer accounts across card updates, while ARN arn_code helps monitor the transaction’s status at each stage, from authorization to settlement. RRN rrn_code allows merchants to retrieve detailed transaction logs for dispute or chargeback investigations.