Transaction Processing

Overview

As far as the transaction processing - if we trigger the command via the REST API, the device switches to the card reader screen waiting for the customer to swipe, tap, or insert their card during the set timeout.

If the user doesn't interact with the device, the session for that card screen reader expires where BluePOS brings you back to the home screen of the application and the REST API receives the Session Timeout error.

In this section, we provide some sample requests for transaction processing. For the comprehensive reference on all the body parameters, refer to the API Reference.

📘

Note

The BluePOS API always initializes a transaction before processing it - whether it’s a sale, authorization, or similar. This acts as an additional safeguard in case of communication errors, packet loss, or related issues during processing.

For example, a sale transaction includes "action": "init" in the trace.history to indicate this initialization step.

JSON

{
  ...
  "trace": {
    "history": [
      {
        "action": "init",
        "requestId": "8f406e72-1edc-4898-a3cc-9c65bc34cd72",
        "correlationId": "dfbfdfb4-6f01-4b74-8f40-da9b331e0ed0",
        "timestamp": "2025-04-25T06:40:55-05:00"
      },
      {
        "action": "transaction",
        "requestId": "6fb13f21-ddba-4d4b-9764-4e7d17e50f02",
        "correlationId": "8b95fca4-8916-48a3-a0a3-fcf705e40648",
        "timestamp": "2025-04-25T06:40:55-05:00"
      }
    ]
  }
  ...
}

Error Handling

Being part of the V4 API, BluePOS API adopts the error codes and responses from the V4.

Some examples include the following:

📘

Note

For the full breakdown of these error objects, refer to General V4 Error Response Codes.

{
  "errorCode": 40004,
  "errorType": "not_found",
  "message": "The requested entity was not found",
  "source": "Transaction",
  "statusCode": 404,
  "traceId": "f106775d-830b-49f6-b579-d2d66f654527",
  "value": "unknown"
}

{
  "errorCode": 40001,
  "errorType": "invalid_request",
  "message": "Transaction ID has already been used",
  "statusCode": 422,
  "traceId": "e5157e71-8ca1-462d-91ea-50c4d43089a4"
}

{
  "message": "Request validation error: Does not conform to API schema.",
  "errorCode": "40001",
  "errorType": "invalid_request",
  "source": "Parameter",
  "value": null,
  "traceId": "5f39c702-90ef-48db-8ad5-5d83dd68588f",
  "details": [
    {
      "source": "Query Parameter",
      "value": null,
      "message": "Invalid value for query parameter \"limit\": number must be at most 10"
    }
  ]
}

Sale Transaction

Request

POST /api/v4/accounts/{accountId}/poi/{serial}/sale

*Required Scopes: pcx:poi:*, pcx:poi:sale

The simplest sale transaction is with only currency and total provided.

{
  "amounts": {
    "currency": "USD",
    "total": "20"
  }
}

We could also provide gratuity for a "sale plus tip" transaction.

{
  "amounts": {
    "currency": "USD",
    "gratuity": "2",
    "total": "20"
  }
}

In this case, once the card screen reader is launched - the tip isn't added to the total amount on the screen but it is treated as the gratuity object for transaction reporting and in response.

Here is an example response:

{
  "amounts": {
    "approved": "20.00",
    "balance": "20.00",
    "currency": "USD",
    "gratuity": "2.00",
    "requested": "20.00"
  },
  "description": "Init tx",
  "status": "CAPTURED",
  "trace": {
    "gpsLocation": {
      "latitude": "",
      "longitude": ""
    },
    "source": "Payconex BluePOS",
    "timestamp": "2025-04-25T11:38:12.000Z"
  },
  "transactionId": "000000050946"
}

The transactionId is response can be re-used to get the transaction metadata when generating a report. See Getting a Transaction.

We could also provide additional trace information data returned back to the REST API and saved as transaction metadata.

The following trace fields can be added as transaction metadata by the merchant.

Request with Trace Data

{
  "amounts": {
    "currency": "USD",
    "gratuity": "2",
    "cashback": "10",
    "total": "20"
  },
  "trace": {
    "cashier": "A920:0820617507",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ]
  }
}

The following trace fields can additionally be specified by the merchant.

🚧

Note

These are user-defined included only in the transaction response and are not saved as transaction metadata for security reasons.

  "trace": {
    /* ... */
    "sourceIp": "192.168.0.14",
    "clientIp": "100.100.10.100",
    "gpsLocation": {
      "latitude": "39.477446",
      "longitude": "-98.059873",
      "accuracy": "100"
    },
    "source": "Custom Source"
  },

Response Example

In response, BluePOS API automatically adds the accurate timestamp.

{
  "amounts": {
    "approved": "20.00",
    "balance": "20.00",
    "currency": "USD",
    "requested": "20.00"
  },
  "description": "Init tx",
  "status": "CAPTURED",
  "trace": {
    "cashier": "A920:0820617507",
    "customId": "asdf123",
    "gpsLocation": {
      "latitude": "",
      "longitude": ""
    },
    "source": "Payconex BluePOS",
    "tags": [
      "ACX42342"
    ],
    "timestamp": "2025-06-04T21:26:22.000Z"
  },
  "transactionId": "000000052246"
}

📘

Customer Name

To reduce potential fraud as a CP transaction, the card.name decrypted and extracted from the card payload always overwrites the customer.name, ensuring the transaction and cardholder's authenticity.

This can also help if there is a typo in the customer's name.

For example, the following request results in the transaction metadata below.

Sale Request

The sale request with the incorrect customer name.

JSON

{
  "customer": {
    "billingAddress": {
      "address1": "123 Plain St",
      "address2": "West Side",
      "city": "Atlanta",
      "company": "Acme Inc.",
      "country": "USA",
      "state": "GA",
      "zip": "90210"
    },
    "email": "[email protected]",
    "name": "Alice Smith",
    "phone": "+14441234321"
  },
  "amounts": {
    "currency": "USD",
    "total": "20"
  },
  "trace": {
    "cashier": "A920:0820617507",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ]
  }
}

Transaction Metadata

As we can see, the authentic card.name overwrites customer.name as the two should be the exact same thing.

JSON

{
  "transactionId": "000000053266",
  "status": "CAPTURED",
  "timestamp": "2025-06-16T12:38:53.000000Z",
  "description": "Init tx",
  "customer": {
    "name": "Jane Smith",
    "email": "[email protected]",
    "phone": "+14441234321",
    "billingAddress": {
      "address1": "123 Plain St",
      "address2": "West Side",
      "city": "Atlanta",
      "state": "GA",
      "zip": "90210",
      "country": "USA",
      "company": "Acme Inc."
    }
  },
  "trace": {
    "cashier": "A920:0820617507",
    "timestamp": "2025-06-16T12:38:49.395Z",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ],
    "source": "PCX V4",
    "history": [
      {
        "action": "init",
        "requestId": "c51cbd01-0b26-4d4d-bfea-c535f237e9d9",
        "correlationId": "882ca48e-cf89-4d31-bf98-7efda2ca19a7",
        "timestamp": "2025-06-16T07:38:50-05:00"
      },
      {
        "action": "transaction",
        "requestId": "8a2cadc8-0cc2-405c-a208-9bffa93038cc",
        "correlationId": "85390b01-a161-49d5-b0b5-13c90db6b8e9",
        "timestamp": "2025-06-16T07:38:50-05:00"
      }
    ],
    "networkTransactionId": "0616MCC315148"
  },
  "amounts": {
    "currency": "USD",
    "approved": "20.00",
    "requested": "20.00",
    "balance": "20.00"
  },
  "auth": {
    "code": "OK2634",
    "processorMessage": "APPROVED",
    "message": "APPROVED",
    "networkName": "MASTERCARD",
    "avsResponseCode": "Y"
  },
  "card": {
    "name": "Jane Smith",
    "last4": "0037",
    "expiry": "1225",
    "brand": "MASTERCARD"
  },
  "binData": {
    "program": "UNKNOWN"
  },
  "transactionType": "SALE",
  "entryMode": "SWIPE",
  "refundObject": {
    "refundBalance": "20.00"
  }
}

Transaction Metadata

In case there is no customer metadata provided in the sale request, the customer name is additionally included for transaction reporting purposes - being the card name as mentioned above.

For example,

JSON

{
  "transactionId": "000000053286",
  "status": "CAPTURED",
  "timestamp": "2025-06-16T13:37:35.000000Z",
  "description": "Init tx",
  "customer": {
    "name": "Jane Smith"
  },
  "trace": {
    "cashier": "A920:0820617507",
    "timestamp": "2025-06-16T13:37:31.915Z",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ],
    "source": "PCX V4",
    "history": [
      {
        "action": "init",
        "requestId": "544e33ff-e657-4fd0-af16-6f9547104f17",
        "correlationId": "d588b9ee-01cd-4cc0-88ef-45dfe93f436b",
        "timestamp": "2025-06-16T08:37:32-05:00"
      },
      {
        "action": "transaction",
        "requestId": "ef20b5a1-f421-4caa-9614-93f605f24b9b",
        "correlationId": "fd819467-5786-4236-b9c3-9e6afe6b7c4c",
        "timestamp": "2025-06-16T08:37:33-05:00"
      }
    ],
    "networkTransactionId": "0616MCC248466"
  },
  "amounts": {
    "currency": "USD",
    "approved": "20.00",
    "requested": "20.00",
    "balance": "20.00"
  },
  "auth": {
    "code": "OK5824",
    "processorMessage": "APPROVED",
    "message": "APPROVED",
    "networkName": "MASTERCARD"
  },
  "card": {
    "name": "Jane Smith",
    "last4": "0037",
    "expiry": "1225",
    "brand": "MASTERCARD"
  },
  "binData": {
    "program": "UNKNOWN"
  },
  "transactionType": "SALE",
  "entryMode": "SWIPE",
  "refundObject": {
    "refundBalance": "20.00"
  }
}

Sale Body Params

These are the descriptions of the fields used in a sale transaction.

amounts

trace

Compare to the V4 API | Get Transaction Metadata.

healthcare

For the comprehensive response examples, refer to the API Reference | Processing a Sale command.

Initializing a Transaction

One of the more important transactions is transaction initialization which guarantees the insurance in case the ECR or the device runs into a communication error, a packet loss, or similar causing the transaction workflow to be interrupted. By pre-saving the transaction entry and some of its metadata, the merchant has the ability to retry processing the same transaction until successful.

First, we use the PayConex™ V4 API to pre-save the transaction entry and fetch its transaction identifier in response.

Request

POST /api/v4/accounts/{accountId}/payments/init

{
  "level2": {
    "merchantReference": "121231",
    "orderId": "1234567",
    "tax": "0.05",
    "zip": "90210"
  },
  "level3": {
    "summaryCommodityCode": "8012",
    "shipFromZip": "12345"
  },
  "customer": {},
  "shippingAddress": {
    "address1": "address1",
    "address2": "address2",
    "city": "Kansas City",
    "state": "AL",
    "zip": "90210",
    "country": "USA",
    "company": "Acme Inc.",
    "recipient": "Jane Smith"
  },
  "trace": {
    "source": "Payconex BluePOS",
    "timestamp": "2025-04-25T07:30:07.603Z"
  }
}

*Required Scopes: pcx:payments:*, pcx:payments:create

📘

Note

We can also specify Level 2 and Level 3 Data that are authorized and adjusted once the transaction is processed via Sale or Auth.

For more details, see:

• PayConex™ V4 API Initializing a Transaction
• Level 2 and Level 3 Transaction Processing

Response

{
  "transactionId": "000000051006",
  "status": "INITIALIZED",
  "shippingAddress": {
    "address1": "address1",
    "address2": "address2",
    "city": "Kansas City",
    "state": "AL",
    "zip": "90210",
    "country": "USA",
    "company": "Acme Inc.",
    "recipient": "Jane Smith"
  },
  "level2": {
    "merchantReference": "121231",
    "orderId": "1234567",
    "tax": "0.05",
    "zip": "90210"
  },
  "level3": {
    "status": "PENDING",
    "summaryCommodityCode": "8012",
    "shipFromZip": "12345"
  },
  "trace": {
    "source": "Payconex BluePOS",
    "timestamp": "2025-04-25T07:30:07.603Z",
    "history": [
      {
        "action": "init",
        "requestId": "61bf7789-8da4-44f0-80e4-501ae7ba5477",
        "correlationId": "a088fbf1-95da-4eaf-a723-0b5640f0bdf1",
        "timestamp": "2025-04-25T07:30:07-05:00"
      }
    ]
  }
}

With the transaction identifier pre-fetched, we are set to trigger our desired transaction including sale, authorization, force, refund, or credit.

POST /api/v4/accounts/{accountId}/poi/{serial}/sale

{
  "transactionId": "000000026646",
  "amounts": {
    "currency": "USD",
    "gratuity": "2",
    "total": "20"
  },
  "description": "TV Purchase #1",
  "trace": {
    "cashier": "A920:0820617507",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ]
  }
}

*Required Scopes: pcx:poi:*, pcx:poi:sale

📘

Note

The transaction remains in an initialized state even if the customer cancels it. It must still be successfully processed for the transaction entry to become a finalized transaction - be it: a sale, authorization, refund, etc.

Getting Transactions

This endpoint returns a summarized list of BluePOS transactions processed through a particular PAX device for generating transaction reports with ease. It defines a rich set of query parameters for filtering the transactions based on your needs.

📘

Note

This set of transactions is a report stored on the device offline and is typically used for end-of-day reporting. As a result, if we process an authorization transaction and capture it via V4, the same transaction in this report stays "AUTHORIZATION" unless we get it via the V4 API. See V4 API | Get a Transaction Metadata.

Query Parameters

GET /api/v4/accounts/{accountId}/poi/{serial}/list-transactions?limit=2

*Required Scopes: pcx:poi:*, pcx:poi:list_transactions

Response

{
  "transactions": [
    {
      "approvedAmount": "20.00",
      "authCode": "OK9639",
      "authMessage": "APPROVED",
      "cardType": "MASTERCARD",
      "entryMode": "SWIPE",
      "last4": "0037",
      "reference": "7642759e-657f-4b6e-beae-522e9619330a",
      "status": "CAPTURED",
      "timestamp": "2025-04-18T15:24:03.000Z",
      "transactionId": "000000050806",
      "transtype": "SALE"
    },
    {
      "approvedAmount": "10.00",
      "authCode": "OK9989",
      "authMessage": "APPROVED",
      "cardType": "MASTERCARD",
      "entryMode": "SWIPE",
      "last4": "0037",
      "reference": "19336147-8b9f-45b6-b4e9-332b8dd6b2ef",
      "status": "AUTHORIZED",
      "timestamp": "2025-04-18T15:24:23.000Z",
      "transactionId": "000000050826",
      "transtype": "AUTHORIZATION"
    }
  ]
}

To view detailed metadata for a transaction in great detail for more comprehensive reports, use the transaction ID 000000022626 of the transaction you wish to retrieve. See below.

🚧

Note

Retrieving a high volume of transactions individually by their identifiers can be resource intensive. For this reason, we have set the maximum limit of 10 items per page. This is a common approach for many of our integrated software vendors. If you would like further assistance, please reach out to the Bluefin Integrations team via [email protected].

JSON

{
  "message": "Invalid value for query parameter \"limit\": number must be at most 10",
  "errorCode": "40001",
  "errorType": "invalid_request",
  "source": "limit",
  "value": 100,
  "traceId": "b3b4a17c-76ab-495a-bbcf-58d97dd04a9f",
  "details": [
    {
      "source": "limit",
      "value": 100,
      "message": "Invalid value for query parameter \"limit\": number must be at most 10"
    }
  ]
}

Getting a Transaction

Since BluePOS transactions are all processed within the PayConex™ system, we can use the transactionId receive the transaction metadata.

This is ideal if the merchant wants to get the transaction metadata in real time as opposed to Gettting Transactions.

For more, see Get Transaction Metadata.

GET /api/v4/accounts/{accountId}/payments/{transactionId}

*Required Scopes: pcx:payments:read, pcx:payments:*

Response

For example, this is what the transaction metadata response of a sale transaction consists of:

{
  "transactionId": "000000050986",
  "status": "CAPTURED",
  "timestamp": "2025-04-25T11:49:54.000000Z",
  "description": "Init tx",
  "customer": {
    "name": "MTIP04"
  },
  "trace": {
    "cashier": "A920:0820617507",
    "timestamp": "2025-04-25T11:49:51.202Z",
    "customId": "asdf123",
    "tags": [
      "ACX42342"
    ],
    "source": "PCX V4",
    "history": [
      {
        "action": "init",
        "requestId": "1a831348-62e8-4a35-858a-ea5040db0fcf",
        "correlationId": "cd2d4feb-fc54-409d-b75c-8b5dcdf531e9",
        "timestamp": "2025-04-25T06:49:51-05:00"
      },
      {
        "action": "transaction",
        "requestId": "f83ff1dd-124b-4c7c-a68b-156af6880a8d",
        "correlationId": "d1a7f61b-b96c-434f-9b3a-66a570bf0fb4",
        "timestamp": "2025-04-25T06:49:52-05:00"
      }
    ],
    "networkTransactionId": "0425MCC252227"
  },
  "amounts": {
    "currency": "USD",
    "approved": "20.00",
    "requested": "20.00",
    "gratuity": "2.00",
    "balance": "20.00"
  },
  "auth": {
    "code": "OK2164",
    "processorMessage": "APPROVED",
    "message": "APPROVED",
    "networkName": "MASTERCARD"
  },
  "card": {
    "name": "MTIP04",
    "last4": "0037",
    "expiry": "1225",
    "brand": "MASTERCARD"
  },
  "binData": {
    "program": "UNKNOWN"
  },
  "transactionType": "SALE",
  "entryMode": "SWIPE",
  "refundObject": {
    "refundBalance": "20.00"
  }
}

Refunding a Transaction

📘

Note

Similar to Capturing an authorization, the refund doesn't update the offline report transaction sale entry. Instead, use V4 API | Get a Transaction Metadata to get the metadata in real time.

For example, if we query for the transaction below after refunding it - it is the same transaction type assigned at the point of processing.

GET /api/v4/accounts/{accountId}/poi/{serial}/list-transactions?transactionId=000000051146

JSON

{
    "transactions": [
       {
         "approvedAmount": "20.00",
         "authCode": "OK9044",
         "authMessage": "APPROVED",
         "cardType": "MASTERCARD",
         "entryMode": "SWIPE",
         "last4": "0037",
         "reference": "4916e056-fd5e-4981-8a7c-c3c1d34e90ef",
         "status": "CAPTURED",
         "timestamp": "2025-04-25T14:01:27.000Z",
         "transactionId": "000000051146",
         "transtype": "SALE"
       }
    ]
}

BluePOS Refund

BluePOS supports its own refund endpoint in addition to the V4 API, enhancing the security and control over refunds of sale transactions processed through devices.

Since the BluePOS Refund adopts the capabilities of the V4 API, processing partial refunds is also a feature. For more, see Refunding a Transaction | Partial Refund.

Request

POST /api/v4/accounts/{accountId}/poi/{serial}/payment/{transactionId}/refund

{
  "amounts": {
    "total": "10.00",
    "currency": "USD"
  }
}

*Required Scopes: pcx:poi:*, pcx:poi:refund

Once this request is run, the device spawns a screen for the customer to confirm the refund for the set amount.

For all the body parameters available for a BluePOS refund, see the API Reference | Initialize a refund.

Response

{
  "amounts": {
    "approved": "10.00",
    "currency": "USD",
    "requested": "10.00"
  },
  "description": "Init tx",
  "status": "VOIDED",
  "trace": {},
  "transactionId": "000000051086"
}

V4 Refund

The PayConex™ V4 API offers a dedicated transaction management endpoint for processing refunds.

As opposed to the BluePOS Refund, the following refund needs the posProfile and deviceProfile specified to identify the POS interaction with the sale. The BluePOS Refund also requires the customer consent so it is the recommended refund the merchant should prefer.

Request

POST /api/v4/accounts/{accountId}/payments/{transactionId}/refund

{
  "posProfile": "ATTENDED_ON_PREM_POS",
  "deviceProfile": "PAX_A77",
  "amounts": {
    "total": "20",
    "currency": "USD"
  }
}

*Required Scopes: pcx:payments:*, pcx:payments:device:*, pcx:payments:card_not_present:*, pcx:payments:refund

📘

Note

In the example above, we perform a full refund. For a partial refund and more information on refunding a transaction via V4 API, check out below:

• Refunding a Transaction
• Point of Sale Profiles
• Device Profiles

Authorization Transaction

An auth transaction takes the exact same set of body parameters as a sale transaction.

Request

Here is a very simple request that you can use for testing.

POST /api/v4/accounts/{accountId}/poi/{serial}/auth

{
  "amounts": {
    "currency": "USD",
    "total": "10"
  }
}

*Required Scopes: pcx:poi:auth, pcx:poi:*

🚧

Note

Note that an authorization transaction is not refundable.

Response

{
  "amounts": {
    "approved": "10.00",
    "balance": "10.00",
    "currency": "USD",
    "requested": "10.00"
  },
  "description": "Init tx",
  "status": "AUTHORIZED",
  "trace": {
    "gpsLocation": {
      "latitude": "",
      "longitude": ""
    },
    "source": "Payconex BluePOS",
    "timestamp": "2025-04-25T12:55:49.000Z"
  },
  "transactionId": "000000051046"
}

Capturing

Next, we are set to capture it.

📘

Note

As noted before, this capture doesn't update the offline report transaction authorization entry. Instead, use V4 API | Get a Transaction Metadata to get the metadata in real time.

For example, if we query for the transaction below after capturing it - it is the same transaction type assigned at the point of processing.

GET /api/v4/accounts/{accountId}/poi/{serial}/list-transactions?transactionId=000000024966

JSON

{
  "transactions": [
    {
      "approvedAmount": "10.00",
      "authCode": "OK7124",
      "authMessage": "APPROVED",
      "cardType": "MASTERCARD",
      "entryMode": "SWIPE",
      "last4": "0037",
      "reference": "e6b7c76a-35d2-4bf5-8b89-7d9ab69a6b16",
      "status": "AUTHORIZED",
      "timestamp": "2025-04-25T13:53:01.000Z",
      "transactionId": "000000024966",
      "transtype": "AUTHORIZATION"
    }
  ]
}

POST /api/v4/accounts/{accountId}/payments/000000024966/capture

{
  "posProfile": "ATTENDED_ON_PREM_POS",
  "deviceProfile": "PAX_A77"
}

*Required Scopes: pcx:payments:process:*, pcx:payments:*

📘

See Also

• Processing an Authorization
• Capturing an Authorization
• Point of Sale Profiles
• Device Profiles

Force Transaction

The force and credit transactions don't entirely support the body parameters as the sale and authorization.

When it comes to a force transaction, the most notable ones are healthcare and ebt. For example, the reason healthcare transactions are not supported for force transactions relates to regulatory and compliance issues specific to the healthcare industry. Healthcare payments often involve highly sensitive personal and insurance-related data.

In a force transaction, a payment is processed without authorization from the card issuer (typically used when a system is offline), which can increase the risk of fraud and non-compliance. Therefore, it is the Payment Processor that permits and enables force transactions. If you wish to enable it, please contact Bluefin support team.

The authorization code for a force transaction is commonly generated by the authorization transaction beforehand. Less commonly, this code can also be provided by the cardholding bank.

Request

POST /api/v4/accounts/{accountId}/poi/{serial}/force

{
  "authCode": "OK4230",
  "amounts": {
    "currency": "USD",
    "total": "10"
  },
  "description": "OFFLINE Transaction"
}

*Required Scopes: pcx:poi:force, pcx:poi:*

See Also: Processing a CNP Force.

Once we run this request, we see that the card screen reader on the device treats this transaction as sale. However, in the PayConex™ gateway - the transaction type and the status is FORCE.

Force Body Parameters

These are the descriptions of the fields used in a sale transaction.

Credit Transaction

By default, credit transactions are disabled on PAX devices to ensure compliance with stringent security protocols and reduce the risk of fraud. This restriction helps maintain the integrity of the transaction process. However, if your business requires the ability to process credit transactions through PAX devices, you can request this functionality by contacting the Bluefin operations team.

🚧

Note

Additionally, credit transactions must be permitted and enabled by the Payment Processor.

The API Key configured on the device also requires the special device credit scope (pcx:payments:device:credit) as this request goes through the V4 API.

For more information, see:

• BluePOS Introduction | API Key Setup
• API Key Management

Request

POST /api/v4/accounts/{accountId}/poi/{serial}/credit

{
  "timeout": 100,
  "amounts": {
    "currency": "USD",
    "total": "10"
  },
  "description": "Credit Transaction - Return"
}

*Required Scopes: pcx:poi:credit, pcx:poi:*

Response

{
  "amounts": {
    "approved": "10.00",
    "currency": "USD",
    "requested": "10.00"
  },
  "description": "Credit Transaction - Return",
  "status": "CREDITED",
  "trace": {
    "gpsLocation": {
      "latitude": "",
      "longitude": ""
    },
    "source": "Payconex BluePOS",
    "timestamp": "2025-04-25T13:04:30.000Z"
  },
  "transactionId": "000000051066"
}

Credit Body Request Params

These are the descriptions of the fields used in a sale transaction.

Timeout Error

If the default or set timeout expires, the REST API receives the following error.

{
  "errorCode": 103,
  "message": "Timeout",
  "value": "FAILED"
}