Query Transaction Status

Use the Status Query service to retrieve the final state of a transaction stored in the Getnet Cloud using its unique identifier. This endpoint is critical for recovering results if a synchronous connection drops or for monitoring the progress of asynchronous operations.

Service Definition

Send a GET request to the specific transaction resource. Replace the {id} placeholder with your recorded transaction ID.
AttributeSpecification
Endpoint URLhttp://pos-domain/api/postxs/{id}
MethodGET
AuthorizationBearer <token>

Required Headers

Include these mandatory headers in the request:

  • env: Environment identifier (e.g., uat).
  • country: Country code (e.g., ar).
  • app: Application identifier (always posintegrado).

Lifecycle State Interpretation

The code field in the response object defines the current state of the transaction within the Getnet Cloud.

1. Transaction Finalized (code: 1)

The operation is complete and has reached a terminal state (Approved or Rejected). The data object contains the full transaction metadata, including authorization codes and final amounts.
json
{ "code": 1, "status": "OK", "message": "TRANSACTION COMPLETED", "data": { "functionCode": 100, "code": 0, "message": "Approved", "authorizationCode": "010929", "amount": 100000 } }

2. Transaction In Progress (code: 2)

The terminal is still interacting with the customer (e.g., waiting for card or PIN) or the authorizer. The status field returns "OK", and the data field remains null until the process concludes.
json
{ "code": 2, "status": "OK", "message": "TRANSACTION IN PROCESS", "data": null }

3. Error or Not Found (code: 0)

The server cannot locate the ID, or a server-side failure occurred. The data field returns as null. Verify the idPosTxs and ensure the request is authorized for your merchant ID.
json
{ "code": 0, "status": "ERROR", "message": "ID NOT FOUND", "data": null }

Operational Best Practices

Adhere to the following guidelines for robust transaction recovery:

  • Automatic Recovery: Implement a polling routine using this endpoint if a synchronous request times out at 90 seconds or reaches the 5-minute maximum wait.
  • Asynchronous Audit: Use this endpoint to manually verify transaction states if your webhook listener fails to receive a callback.
  • Log IDs Immediately: Store the idPosTxs in your local database as soon as it is returned to ensure you can recover the transaction status in the event of a crash.

Next Steps

Now that you can query transaction states, ensure you understand the associated timeouts and webhook flows: