InfraPSP Docs (v1)

Welcome to InfraPSP API documentation. This API is used to interact with the InfraPSP services.

This API uses the following security schemes for the authorization header:

Authorization: Bearer {apiKey}.{apiSecret}

Authorization: Basic {apiKey}:{apiSecret}

Authorization: Bearer {jwtToken}

To firstly get your API Key pair (Key + Secret), you must create it through the dashboard or via API endpoint (see Auth section for more details).

Field {apiKey} refers to the key value from the api key, and {apiSecret} is the secret part. The later can only be seen in the response of the api key creation, so keep it safe as it is not recoverable. You can also use the {jwtToken} issued after logging through the dashboard.

Our APIs works only with UTC time zone. Make sure you are converting your date inputs to UTC before sending.

Ex: If you are at São Paulo/Brazil (UTC -03:00) and want to create a pix transaction that expires at the end of December 31th 2024, you need to send this date as 2024-01-01T02:59:59.999Z as it is the representation of the desired date on UTC time zone.

All currency values in our APIs are treated as cents. This includes transaction amounts, transfer values, splits, items, shipping values, balance, and so on. Remember to multiply the value by 100 before sending it through the endpoints. For example, an $100 amount would be represented by 10000 and should be sent this way.

A large portion of the listing APIs support date range queries based on different fields depending on the entity. These queries have a range limit of 1 year. This means that a date range must be an interval that is less than or equal to 365 days, or else they will return error. This is also true for queries missing one or both values of the date range, as the values of gte and lte will default to now - 1 year and now respectively.

Here we show schema and examples of expected errors that can be returned from our APIs in every request. All error responses comes with a code to identify the problem and a message describing the error. Additionally, sometimes the error response can contain more details about what happened during the request and why was not able to fullfil it.

Example for a 400 Bad Request error:

{
  "code": "API_ERROR",
  "message": "some api error",
  "detail": {
    "errors": [
      {
        "path": "parameterName"
      }
    ]
  }
}

Example for a 404 Not Found error:

{
  "code": "NOT_FOUND",
  "message": "not found"
}

Example for a 500 Internal Server Error error:

{
  "code": "INTERNAL_SERVER_ERROR",
  "message": "internal server error"
}

The sandbox environment allows you to test API functionality with predictable behaviors based on specific input values. Use the following patterns to simulate different scenarios:

Payment Method Settings

Control transaction creation behavior using methodSettings.payerRequest:

Transaction Amount

Control payment flow using the transaction amount value:

Examples:

• Amount 1010: Transaction will be paid after 10 seconds
• Amount 2020: Transaction will be paid after 20 seconds
• Amount 1001: Transaction will fail immediately

Available Credit Cards

Only the cards listed below will work in sandbox tests. All others will result in a failed transaction.

Customer Document Number

Control authorization flow using customer.documentNumber:

Transfer Amount

Control transfer completion using the amount value:

Examples:

• Amount 1010: Transfer will complete after 10 seconds
• Amount 3000: Transfer will complete immediately (0 seconds delay)
• Amount 1501: Transfer will fail

Note: All amounts in the sandbox follow the same currency format as production (values in cents). The delay timing only applies to sandbox environment and is used for testing webhooks and status polling.