Skip to main content

CardPointe Connector (Technical Documentation)

Written by Philippe Trussart

Overview

The CardPointe connector provides read-only payment and settlement data from CardPointe. It retrieves three related datasets:

  • settled_transactions — settlement batch summaries

  • settled_transaction_details — individual transactions associated with settlement data

  • profiles — payment profiles associated with retrieved transactions

The connector does not create, update, refund, void, or otherwise modify CardPointe data.


Authentication

The connector requires:

username password merchant_id

Requests use Basic Authentication against:

https://donorpro.prinpay.com/cardconnect/rest

API Requests

The connector uses GET requests only. There are no POST, PUT, PATCH, or DELETE requests.

Endpoint

Method

Purpose

/settlestat?merchid={merchant_id}&date={MMDD}

GET

Retrieves settlement batches for a specific date

/inquire/{retref}/{merchant_id}

GET

Retrieves details for an individual transaction

/profile/{profile_id}/{account_id}/{merchant_id}

GET

Retrieves the payment profile associated with a transaction


Sync Behavior

The connector does not maintain an incremental bookmark. Instead, every run re-fetches a recent date window controlled by:

days_back

The sync always ends on yesterday, so the current day's settlement activity is not included until a later run.

If days_back is not supplied, the connector retrieves approximately the previous 4 completed days.

There is an important configuration nuance: when days_back is explicitly supplied, the connector adds 1 to the configured value. For example, configuring days_back = 4 results in a five-day inclusive date range, while leaving it empty uses four days.

Because each run re-reads the recent window, repeated records between syncs are expected.


Record Relationships

Data is retrieved hierarchically:

Settlement Batch       ↓ Transaction       ↓ Payment Profile

For each settlement date, the connector first retrieves settlement information. Transaction references are then used to retrieve detailed transaction records individually.

If a transaction detail contains all three of:

profileid acctid merchid

the corresponding CardPointe profile is retrieved as well.

This means the profiles table is not a complete export of every profile in CardPointe. It only contains profiles encountered through transactions processed by the connector.


Unique Keys

The connector identifies records using:

settled_transactions         → batchid settled_transaction_details  → retref profiles                     → profileid + acctid

These keys are important because overlapping sync windows mean the same source records may be retrieved on multiple runs.


Deletes

The connector does not actively detect or synchronize deleted records.

Although the table keys are declared as deletion keys in the sync metadata, the connector does not:

  • Request a deleted-record feed

  • Compare one source snapshot to another

  • Emit explicit delete events

A record removed upstream should therefore not be assumed to disappear automatically from downstream data.


Known Limitations & Notable Behavior

  • Only recent settlement history is retrieved. There is no persistent bookmark or automatic historical backfill. Data availability depends on the configured days_back window.

  • The current day is excluded. The extraction window ends at yesterday, which is appropriate for settled activity but means today's transactions will not appear immediately.

  • Profiles are transaction-driven. A profile is only retrieved when a processed transaction contains profileid, acctid, and merchid. The profiles dataset should not be considered a complete CardPointe profile inventory.

  • Transaction details require individual API calls. Each transaction reference results in a separate /inquire request, and some of those result in an additional profile request. High transaction volumes can therefore generate many API requests.

  • No retry or rate-limit handling is implemented. Requests are made directly, so temporary API or network failures are not explicitly retried by the connector.

  • transaction_date is connector-generated. For settlement and detail records, this field is populated using the date currently being queried rather than copied from the CardPointe transaction response. Use fields such as authdate, capturedate, or settledate when the actual transaction lifecycle date is required.

  • The settlement API is queried using MMDD, not a full year/date. The connector converts each processing date to month/day before calling /settlestat. This is worth keeping in mind when troubleshooting year boundaries or attempting unusually large historical windows.

  • There is a significant multi-batch limitation in the current implementation. All settlement batches returned for a date are written to settled_transactions, but transaction processing occurs after the loop over those batches and uses the txns collection from only the final batch returned for that date. If CardPointe returns multiple settlement batches for the same date, transaction details and profiles from earlier batches may therefore be omitted.

Did this answer your question?