Overview
The CardPointe connector provides read-only payment and settlement data from CardPointe. It retrieves three related datasets:
settled_transactions— settlement batch summariessettled_transaction_details— individual transactions associated with settlement dataprofiles— 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 |
| GET | Retrieves settlement batches for a specific date |
| GET | Retrieves details for an individual transaction |
| 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_backwindow.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, andmerchid. 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
/inquirerequest, 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_dateis 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 asauthdate,capturedate, orsettledatewhen 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 thetxnscollection 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.
