Checkout.com (Edge)

Configure Checkout.com as a Source in your Pipeline

Perform the following steps to configure your Checkout.com Source:

1. Click Pipelines in the Navigation Bar.

2. Click + Create Pipeline in the Pipelines List View.

3. On the Select Source Type page, select Checkout.com.

4. On the Select Destination Type page, select the type of Destination you want to use.

5. In the Configure Source screen, specify the following:

   

   • Source Name: A unique name for your Source, not exceeding 255 characters. For example, Checkout Payments Source.

   • In the Connect to Checkout.com section, specify the following:

     • Environment: The Checkout.com environment from which you want to ingest data. Select Production or Sandbox. Default value: Production.

     • Access key ID: The key ID of the access key that you created in Checkout.com. It starts with ack_.

     • Access key secret: The access key secret of the access key that you created in Checkout.com.

     • Entity ID: The ID of the entity whose balances you want to ingest, which you copied from the Key details page. It starts with ent_.

     • Prefix: The prefix of the API base URL of your account, which you obtained from the Checkout.com Dashboard. For example, a1b2c3d4.

6. Click Test & Continue to test the connection to your Checkout.com Source. Hevo obtains an OAuth 2.0 token using the access key, and then checks whether the key can list reports, search payments, read payment details, read customers, read disputes, and read the balances of the entity. The test fails if the access key, the prefix, or the Entity ID is incorrect, or if the key cannot read any of this data. If the key is not granted some of the scopes required by Hevo, the test succeeds, but Hevo cannot ingest the objects that need those scopes. Once the test is successful, you can proceed to set up your Destination.

Data Replication

Hevo replicates data for all the objects selected on the Configure Objects page during Pipeline creation. By default, all supported objects and their available fields are selected. However, you can modify this selection while creating or editing the Pipeline.

Hevo ingests the following types of data from your Source objects:

• Historical Data: The first run of the Pipeline ingests all the data of the selected objects. For the payment object and the objects ingested along with it, Hevo ingests the payments requested on or after January 1, 2015. For the report object and the report line item objects, Hevo ingests the reports created on or after January 1, 2015.

• Incremental Data: Once the historical load is complete, Hevo ingests data as per the sync frequency:

  • For the dispute object, Hevo ingests the disputes created or updated since the previous run, based on the last_update field.

  • For the report object, Hevo ingests the reports created since the previous run. For the financial_action_report, financial_action_by_payout_report, balance_report, and payout_report objects, Hevo ingests the line items of those reports.

  • For the payment object, Hevo ingests the payments listed in the Financial Actions reports created since the previous run. Checkout.com creates the Financial Actions report of a day at about 03:10 UTC on the next day. Therefore, a payment is ingested in the first run after the report of the day on which the payment was made is created. As the report lists every financial action, such as a refund or a chargeback, Hevo also ingests the changes to older payments. The objects that contain the details of a payment, such as payment_action and payment_item, and the customer, customer_meta_data, instrument_bank_account, and instrument_card objects of the customers of these payments, are ingested along with the payment object.

  • For the balance object, Hevo ingests the entire data in each run.

You can resync only the balance, dispute, balance_report, financial_action_by_payout_report, financial_action_report, and payout_report objects. To resync the report object, or the payment object and the other objects ingested along with it, resync the financial_action_report object.

Checkout.com limits the number of API requests that an account can make. Read API rate limits. If a limit is reached, Hevo retries the request up to three times, waiting 30 seconds between the attempts, or for the duration that Checkout.com specifies. If the limit is still exceeded, Hevo loads the data read so far for the dispute, payment, report, and report line item objects, and in the next run, resumes reading from the point at which it stopped. For the balance object, the object is not marked as failed, and Hevo reads all the balances again in the next run.

Note: You can create a Pipeline with this Source using either the Merge or the Append load mode. Merge is the default load mode, and you can change the load mode for each object. If the dispute object uses the Append load mode, its Destination table can contain duplicate records, as Hevo reads the disputes updated in the hour before the previous run again. If the balance object uses the Append load mode, Hevo loads a full copy of the balances in each run.

Schema and Primary Keys

Hevo uses the following schema to upload the records in the Destination. For a detailed view of the objects, fields, and relationships, click the ERD.

Click to view ERD

The primary key of the customer, dispute, payment, and report objects is id. The following objects use other primary keys:

• balance: currency_account_id.

• balance_report, financial_action_by_payout_report, and payout_report: report_id, report_file_id, and index_id.

• financial_action_report: action_id, breakdown_type, and fee_detail.

• customer_meta_data: customer_id and name.

• instrument_bank_account and instrument_card: customer_id and id.

• payment_action: id and payment_id.

• payment_action_meta_data: payment_action_id, payment_action_payment_id, and name.

• payment_amount_allocation: payment_id and id.

• payment_item: payment_id and index.

• payment_meta_data: payment_id and name.

• payment_source_bancontact, payment_source_eps, payment_source_giropay, payment_source_klarna, payment_source_knet, payment_source_multibance, and payment_source_p_24: index and payment_id.

• payment_source_card: payment_id and fingerprint_token.

• payment_source_currency_account, payment_source_qpay, and payment_source_sepa: id and payment_id.

Data Model

The following is the list of tables (objects) that are created at the Destination when you run the Pipeline: