CCBill

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Error decoding	limited
API response parsing	limited
Webhook / notification parsing	limited
Timeline	limited
Event correlation	limited
Diagnostic rules	limited

Supported input

Format	Description	Status
`ccbill.webhook`	Webhooks (20 event types), URL-encoded or JSON body. The event type is sent only in the URL query string.	limited
`ccbill.background_post`	Background Post to the Approval Post URL or Denial Post URL (form fields)	supported
`ccbill.rest.charge`	RESTful Transaction API charge response (approved, declineCode, declineText, denialId, subscriptionId), media types v1 and v2	supported
`ccbill.rest.error`	RESTful API and 3DS error envelope (id, url, errors[], generalMessage, errorCode, timestamp)	supported
`ccbill.rest.payment_token`	RESTful API payment token object (recognized, not analyzed)	unsupported
`ccbill.legacy.api`	Legacy subscriptionManagement.cgi and billingApi.cgi CSV / XML responses (result codes are in the catalog; the CSV and XML text cannot be imported)	unsupported
`ccbill.widget`	CCBill Advanced Widget (JavaScript) result and error objects	unsupported
`ccbill.datalink`	Data Link extract CSV (merchant-configured columns)	unsupported

Notification delivery

Repeated deliveries are recognized by Background Post: subscription_id (approval) or denialId (denial). Webhooks: none (CCBill documents no event id or delivery id); CCBill documents that notifications can be delivered more than once.
Delivery order: not documented by the provider.
Make the Background Post handler idempotent per subscription_id or denialId, because CCBill resends unsuccessful posts up to 30 times. For webhooks, deduplicate in your own system (for example on eventType, subscriptionId, transactionId and timestamp); CCBill documents no delivery key, and up to four webhook URLs can receive the same event.

Known limitations

The webhook event type is sent only in the URL query string (eventType), never in the body. It is read from a pasted raw HTTP request or full URL; when only the body is pasted, it is inferred from the field set only where the documented field tables make it unambiguous.
Body-only webhooks that cannot be told apart are reported as an unidentified event with the candidate event types: Refund and Void have identical fields, Upgrade, UpSale and CrossSale differ only by event type, and an Expiration body (subscriptionId, clientAccnum, clientSubacc, timestamp) is a subset of every other event. Stage and outcome are only set when every candidate shares them.
CCBill documents no webhook signature, event id, retry policy, acknowledgement rule or delivery order; authenticity guidance is IP-based only. A pasted webhook or Background Post is never treated as verified. Webhooks get no delivery key.
Webhook failureCode is described as a decline code sent from the bank, with the example BE-140, which matches no published table. Numeric values are decoded with the decline code table at possible confidence; other values are shown verbatim with failureReason and insufficient confidence.
Decline code 15 has two documented meanings (account still being processed, and declined by bank in every billing API example); both are shown with possible confidence.
REST error numbers 100105 to 100109 mean different things at HTTP 400 and HTTP 500, 200000 is both the REST validation error and the 3DS unknown error, and 100100 also appears in a generic HTTP 500 example. Without the HTTP status the meanings are listed and confidence is reduced.
REST v1 returns subscriptionId, and v1 and v2 return denialId, as JSON numbers larger than 2^53. Their precision is lost when the JSON is parsed, so such identifiers are not used as references and are flagged; string identifiers (v2 subscriptionId) are kept as sent.
The REST declineCode is decoded with the Background Post decline table, which matches the documented REST examples; CCBill does not state explicitly that it is the same code space, so confidence is possible.
Webhook timestamps (YYYY-MM-DD HH:MM:SS) have no documented time zone. They are read as UTC to order events; the absolute time may be offset.
Whether transactionId on Refund, Void, Chargeback and Return is the original sale or the reversal record is not documented. Events are grouped by subscriptionId, transactionId, denialId and originalSubscriptionId; paymentAccount (a card hash) is never used for correlation.
Only chargeback initiation is documented; later dispute stages and whether a Cancellation or Expiration follows a refund or chargeback are not documented. The rebill retry schedule is not documented beyond nextRetryDate.
The exact eventType strings for RenewalSuccess and RenewalFailure are not shown literally in the documentation.
Legacy API CSV and XML responses, Data Link CSV extracts, Advanced Widget objects and Dynamic Pricing errors are not imported; legacy result codes and subscription statuses are available in the catalog only.
The Background Post content type is not documented. A form body pasted without HTTP headers must be URL-encoded (spaces as + or %20) to be read as form data.
Payloads from the ISO Payment Gateway product are out of scope: it has no public technical documentation.

Examples

CCBill: rebill declined: A RenewalFailure webhook: a recurring charge failed and CCBill reports the next retry date.
CCBill: webhook as a raw HTTP request: The event type is read from the URL query string; the body alone does not carry it.
CCBill: Background Post denial: A declined sale decoded from CCBill's numbered decline codes.

Provider documentation

PandaPayLens is not affiliated with CCBill. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.