> ## Documentation Index > Fetch the complete documentation index at: https://docs.chip-in.asia/llms.txt > Use this file to discover all available pages before exploring further. > Schedule a statement generation. # Schedule a statement With this request, you can schedule a statement generation for a company. In a response, you will get an object with the following structure. Main fields to look out for here are `id`, `status` and `download_url`. ## OpenAPI ````yaml _openapi-chip-collect POST /company_statements/ openapi: 3.1.0 info: title: Public REST API version: v1 description: > All the endpoints below have a prefix of `https://gate.chip-in.asia/api/v1` (e.g. `POST https://gate.chip-in.asia/api/v1/purchases`). You will need your API key that you can obtain in the Developers section in your account. Please use this key as a bearer token in the Authorization header included in every request: `Authorization: Bearer `. You can generate and manage your API keys here :
https://portal.chip-in.asia/collect/developers/api-keys Your Brand ID is required for certain endpoints. You can find it here :
https://portal.chip-in.asia/collect/developers/brands Before starting the development, we recommend checking out the list of ready-to-go connectors to the popular platforms we’ve already built for you. It might save you some precious time if you use one of these to develop your project. Plugins: [WooCommerce](https://gate.chip-in.asia/apis/plugins/WooCommerce%20v3.5+), [Gravity Forms](https://gate.chip-in.asia/apis/plugins/Gravity%20Forms), [OpenCart](https://gate.chip-in.asia/apis/plugins/OpenCart%20v3.0+), [Magento](https://gate.chip-in.asia/apis/plugins/Magento%20v2.0+), [PrestaShop](https://gate.chip-in.asia/apis/plugins/PrestaShop%20v1.7+) Libraries: [PHP](https://gate.chip-in.asia/apis/libraries/PHP), [Java](https://gate.chip-in.asia/apis/libraries/Java), [C#](https://gate.chip-in.asia/apis/libraries/C%23), [Node.js](https://gate.chip-in.asia/apis/libraries/Node.js) SDKs: [iOS](https://gate.chip-in.asia/apis/sdks/iOS), [Android](https://gate.chip-in.asia/apis/sdks/Android) *** # Online Purchases ## Prebuilt payment flow — Redirect Redirect integration allows running payments using the prebuilt payment flow. To accept payments in your application or website via redirect, use `POST /purchases/` request to create the `Purchase` and receive the `checkout_url`. Redirect the customer to the `checkout_url` to enter their card details for processing. After the payment is processed, the system will redirect the customer back to your website (take note of `success_redirect`, `failure_redirect`). *You have three options to check payment status:* 1. Use `success_callback` parameter of the `Purchase` object. 2. Use `GET /purchases//` request. 3. Set up a Webhook using the Developers section of your account or use Webhook API to listen to `purchase.paid`, or `purchase.payment_failure` event on your server. Setting the `skip_capture` flag to `true` allows you to separate the authentication and payment execution steps, allowing you to reserve funds on the customer's card account for some time. This flag can also enable preauthorization capability, allowing you to save the card without a financial transaction, if possible. If the customer agrees to store his card for future purchases, there will be an option to pay with a single click next time. To enable this, create a `Client` object for each of your clients and provide `client_id` parameter value in your Purchase creation requests. To create a Purchase, you must specify the `Brand ID` and `API key`. You can find both in the Developers section of your account. ## Custom payment flow — Direct Post Direct post integration allows running payments through the custom payment flow. To accept payments in your application or website, use `POST /purchases/` request to create a `Purchase`. To capture customers card details use an HTML `
` hosted on your website with `method="POST"` and `action` pointing to the `direct_post_url` of the transaction. You will also need to fill the form with ``'s for the fields with card details. As a result, when a customer submits their card details, it will be posted straight to our system, allowing you to customize the checkout as you wish. At the same time, your PCI DSS requirement is only raised to Self-Assessment Questionnaire (SAQ A-EP), as your system doesn't receive or process card data. For more details, see the documentation on Purchase's `direct_post_url` field. ### Tokenization & recurring payments You can store card tokens and charge the respective cards without user interaction if the payment channel supports tokenization. When you pass `remember_card=on` to `direct_post_url`, the respective `Purchase`'s ID will serve as a card token. This initial `Purchase` will have the `is_recurring_token` field set to `true`. To charge the tokenized card once again, create a new Purchase and then call the `POST /purchases/{new_purchase_id}/charge/`. In the request body, provide `"recurring_token": "initial_purchase_id"`. When the request succeeds (response code `200`), the new Purchase will become paid. The token will be persisted in the Purchase's recurring_token field. Use `"recurring_token": "initial_purchase_id"` in all the upcoming `POST /purchases/{new_purchase_id}/charge/` requests. If you wish to delete the recurring token stored for the initial `Purchase`, use the `POST /purchases/{initial_purhcase_id}/delete_recurring_token/` request. Its `is_recurring_token` will reset to `false`. ## Testing Integration It’s possible to test-drive all checkouts using a test Purchase. For a successful payment, you can use the following card numbers: * 4444 3333 2222 1111 - non-3D Secure card * 5555 5555 5555 4444 - 3D Secure card For both cards, please use: * any cardholder name * any expiry larger or equal to the current month/year * CVC = 123 For a failed payment, please change the CVC or expiration date. When using a 3D Secure enrolled card in S2S checkout, an incorrect CVC will trigger an authorization failure on the S2S callback step (after the customer returns from test ACS). Using a wrong expiry date emulates data validation failure and results in immediate error before that step. *** # Callbacks Two methods for defining asynchronous callbacks are supported - `Purchase` success callbacks and webhooks. ## Purchase success callbacks `Purchase` success callbacks are defined by providing a target URL in the `success_callback` field on `Purchase` creation (see [POST /purchases/](#/Purchases/purchases_create)). The system will generate a callback when: * a `Purchase` with `skip_capture=false` is successfully paid; * a `Purchase` with `skip_capture=true` is successfully captured (see [POST /purchases/{id}/capture/](#/Purchases/purchases_capture)); * a `Purchase` is successfully paid using a recurring token (see [POST /purchases/{id}/charge/](#/Purchases/purchases_charge)); These callbacks pass a JSON-encoded `Purchase` as their payload. The payload represents a snapshot of the state of the `Purchase` when the event was created. The payload will include an `event_type` field to indicate which specific event (see [Event schema](#model-Event)) triggered the callback. The payload is signed using a company-wide key pair. You can obtain the public key with `GET /public_key/`. See the `Authentication` section below for more details. ## Webhooks For creating and modifying webhooks, see the Webhook [CRUD API specification](#operations-tag-Webhooks). `Webhook` callback payloads are signed using a dedicated key pair. You can obtain the public key from `Webhook.public_key`. See the [Authentication](#callback-auth) section below for more details. ## Delivery protocol When a callback is not successfully delivered (received by the target server and responded to with a 200 series HTTP response code), the system will make up to 8 additional attempts at exponentially increasing intervals between attempts. No further delivery attempts will be made if the callback is not successfully delivered 36 hours after triggering. Please note that due to the asynchronous nature of network requests, it is possible for a callback delivery confirmation (HTTP response with a 200 series status code) to not properly arrive from the callback's target server. Therefore it is possible in case of severe network faults for the target server to receive a callback, respond to it with a 200 series HTTP status code and then receive the same callback after an interval. Callback deliveries are guaranteed to be sequential to events triggered on their source objects. For example, when registering webhooks for both the `purchase.created` and `purchase.paid` events, there will be no `purchase.paid` callbacks for this `Purchase` until all `purchase.created` callbacks for this `Purchase` are successfully delivered. ## Authentication Payloads are signed using asymmetric A.K.A. public-key cryptography to guarantee the authenticity of delivered callbacks. Each callback delivery request includes an X-Signature header field. This field contains a base64-encoded RSA PKCS#1 v1.5 signature of the SHA256 digest of the request body buffer. You can obtain the public key for `Webhook` authentication from `Webhook.public_key` of the corresponding `Webhook`. You can obtain the public key for success callback authentication from [GET /public_key/](#operations-Public_Key-public_key). Please note the provider is not responsible for any financial losses incurred due to not implementing payload signature verification. servers: - url: https://gate.chip-in.asia/api/v1 security: - bearerAuth: [] paths: /company_statements/: post: tags: - Company Statements summary: Schedule a statement description: >- Schedule a statement generation. With this request, you can schedule a statement generation for a company. In a response, you will get an object with the following structure. Main fields to look out for here are `id`, `status` and `download_url`. operationId: company_statements_create parameters: - $ref: '#/components/parameters/from' - $ref: '#/components/parameters/to' - $ref: '#/components/parameters/paid_from' - $ref: '#/components/parameters/paid_to' - $ref: '#/components/parameters/updated_from' - $ref: '#/components/parameters/updated_to' - $ref: '#/components/parameters/brand_id' - $ref: '#/components/parameters/shop_id' - $ref: '#/components/parameters/q' - $ref: '#/components/parameters/products' - $ref: '#/components/parameters/total' - $ref: '#/components/parameters/currency' - $ref: '#/components/parameters/payment_method' - $ref: '#/components/parameters/three_d_secure' - $ref: '#/components/parameters/country' - $ref: '#/components/parameters/status' - $ref: '#/components/parameters/product' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/CompanyStatementBody' example: format: csv timezone: UTC responses: '201': description: OK content: application/json: schema: $ref: '#/components/schemas/CompanyStatement' '400': $ref: '#/components/responses/400' security: - bearerAuth: [] components: parameters: from: in: query name: from description: >- Filter result set to only include values older or equal to the provided Unix timestamp schema: type: integer to: in: query name: to description: >- Filter result set to only include values younger than the provided Unix timestamp schema: type: integer paid_from: in: query name: paid_from description: >- Filter paid result set to only include values older or equal to the provided Unix timestamp schema: type: integer paid_to: in: query name: paid_to description: >- Filter paid result set to only include values younger than the provided Unix timestamp schema: type: integer updated_from: in: query name: updated_from description: >- Filter result set to only include values older or equal to the provided last modification time Unix timestamp schema: type: integer updated_to: in: query name: updated_to description: >- Filter result set to only include values younger than the provided last modification time Unix timestamp schema: type: integer brand_id: in: query name: brand_id description: Filter result set to only include the specified brand UUID(s) schema: type: string format: uuid shop_id: in: query name: shop_id description: Filter result set to only include the specified shop UUID(s) schema: type: string format: uuid q: in: query name: q description: >- Filter result set to only include results including a specified text (search over a ton of text fields) schema: type: string format: string products: in: query name: products description: >- Filter result set to only include results including a specified text in products schema: type: string format: string total: in: query name: total description: >- Filter result set to only include results with a total between min and max value. Must include 2 values, if any - (min, max). schema: type: string format: float currency: in: query name: currency required: true description: >- Filter result set to only include specified currency(ies). The value must be in uppercase. schema: type: string payment_method: in: query name: payment_method description: >- Filter result set to only include specified payment methods(s). See PaymentMethod fro more information. schema: $ref: '#/components/schemas/PaymentMethod' three_d_secure: in: query name: three_d_secure description: Filter result set to only include results with a 3-D verification. schema: type: string format: bool country: in: query name: country description: >- Filter result set to only include specified client country(ies) in ISO 3166-1 alpha-2 format schema: type: string format: ISO 3166-1 alpha-2 status: in: query name: status description: >- Filter result set to only include results with a specific status. See Purchase and Payout for more information. schema: type: string format: string product: in: query name: product description: >- Filter result set to only include specified products(s). See TransactionProduct fro more information. schema: $ref: '#/components/schemas/TransactionProduct' schemas: CompanyStatementBody: type: object properties: format: type: string maxLength: 32 description: 'Statement format, available formats: `csv`, `xlsx`.' timezone: type: string format: TZ database name description: Timezone to localize statement-specific timestamps example: Europe/Oslo CompanyStatement: type: object properties: format: type: string maxLength: 32 description: 'Statement format, available formats: `csv`, `xlsx`.' timezone: type: string format: TZ database name description: Timezone to localize statement-specific timestamps example: Europe/Oslo is_test: type: boolean description: >- Indicates this is a test object, created using test API keys or using the merchant portal while in test mode. company_uid: type: string format: uuid description: ID of the Company. query_string: type: string description: Query parameters used to generate statement. status: type: string description: >- Status of statement generation e.g. `pending`, `processing`, `success`. download_url: type: string description: Download URL of a statement. began_on: description: Date and time for the beginning of statement generation process. allOf: - $ref: '#/components/schemas/UnixTimestamp' finished_on: description: Date and time for finishing the statement generation process. allOf: - $ref: '#/components/schemas/UnixTimestamp' created_on: description: Object creation time allOf: - $ref: '#/components/schemas/UnixTimestamp' updated_on: description: Object last modification time allOf: - $ref: '#/components/schemas/UnixTimestamp' type: type: string description: Statement request type id: type: string format: uuid description: ID of a statement PaymentMethod: type: string description: |- Payment method used to execute the transaction. - crypto_coin: Crypto Coin - dnqr: Dnqr - duitnow_qr: Duitnow Qr - fpx: FPX B2C - fpx_b2b1: FPX B2B1 - maestro: Maestro payment card - mastercard: Mastercard payment card - mpgs_apple_pay: Apple Pay - mpgs_google_pay: Mpgs Google Pay - razer: Razer - razer_atome: Razer Atome - razer_grabpay: Razer Grabpay - razer_maybankqr: Razer Maybankqr - razer_shopeepay: Razer Shopeepay - razer_tng: Razer Tng - unknown: Payment method could not be determinded - visa: Visa payment card enum: - crypto_coin - dnqr - duitnow_qr - fpx - fpx_b2b1 - maestro - mastercard - mpgs_apple_pay - mpgs_google_pay - razer - razer_atome - razer_grabpay - razer_maybankqr - razer_shopeepay - razer_tng - unknown - visa TransactionProduct: type: string description: >- Product category the transaction belongs to. - bank_payment: bank_payment (Payment.payment_type == "bank_payment") - custom_payment: custom_payment (Payment.payment_type == "custom_payment") - invoice: Purchase created as an invoice through the merchant portal - purchase: Purchase created through the merchant API (Purchase.product == "purchases") - refund: refund (Payment.payment_type == "refund") - subscription: Purchase created using a subscription enum: - bank_payment - custom_payment - invoice - purchase - refund - subscription UnixTimestamp: type: integer format: Unix timestamp (seconds) example: 1619740800 responses: '400': description: Invalid data submitted or request processing error content: application/json: schema: type: object example: | { "__all__": { "message": "descriptive error message", "code": "error_code" } } securitySchemes: bearerAuth: type: http scheme: bearer ````