NETbilling

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by Ecom_Ezic_Response_TransactionID and Ecom_Ezic_Response_StatusCode (NETbilling documents no event id; trans_id is unique per transaction).
• Delivery order: not documented by the provider.
• Make the postback handler idempotent per transaction ID. NETbilling does not document postback retries, acknowledgement or ordering.

Known limitations

• Decline reasons are read from auth_msg, which NETbilling says is processor specific, may change and is not intended to be machine readable. Messages are matched as whole texts (several trailing numbers are reused with different meanings), so every auth_msg decoding has at most possible confidence; unmatched texts are reported as unknown with insufficient confidence.
• The meanings of avs_code, cvv2_code and reason_code2 are only available behind the NETbilling merchant login; their values are shown but not decoded.
• NETbilling says unexpected status_code values other than 0 and F should be treated as success. PandaPayLens does not follow that for analysis: unknown status codes are reported with an unknown outcome.
• status_code=T with auth_msg OFFLINE RECORD and a 3ds_url means a 3-D Secure 2 challenge is pending and nothing was authorized; it is shown as pending authentication. OFFLINE RECORD without a 3ds_url is shown with an unknown outcome.
• status_code=D returns the original transaction's trans_id; Direct Mode 3.2 does not say whether the original was approved, so the duplicate response has an unknown outcome.
• Direct Mode 3.2 responses do not say which operation (auth, sale, capture, refund, credit, undo) produced them and do not echo orig_id or any merchant reference. status_code=1 is shown with the generic stage payment, and refunds or captures cannot be linked to their parent transaction from the response alone.
• Direct Mode exceptions are non-200 HTTP statuses with an empty body; the error text and the 5-digit sub-code of 699/799 are only in the HTTP reason phrase. PandaPayLens core keeps only the numeric status and rejects HTTP messages with an empty body, so pasted exceptions cannot be analyzed from text today; when such a record reaches the adapter it is decoded by status range only. Only 604 and 699 sub-code 20112 are documented.
• Test mode is recognized only when auth_msg starts with TEST. The documented amount rules (tens digit: approve or decline, hundreds digit: AVS letter, thousands digit: CVV2 letter) are shown as expectations for amounts below 10000; whole-thousand amounts and amounts of 10000 or more are not explained further in the documentation. Fraud controls also run in test mode.
• The Postback CGI is experimental: NETbilling publishes no example body, content type, acknowledgement, retry, ordering or source IP rules, and field names and encodings are configurable per payment form. Only the default Ecom_Ezic_Response_* names are analyzed. The return URL redirect carries the same fields and cannot be told apart from the postback.
• Whether rebills, refunds, chargebacks, cancellations or expirations produce postbacks is not documented. No analyzed format marks a charge as a rebill, so isRecurring is only set to false for documented signups.
• The postback delivery key is the transaction ID plus status code; NETbilling documents no event id and no duplicate delivery behavior. Ecom_Ezic_Response_IssueDate has no documented format and is not used as event time. Ecom_Cost_Total has no documented currency, so hosted form amounts are not normalized.
• Member Update 1.1 GET responses are experimental: only M_MEMBER_STATUS and the member, signup and template identifiers are documented in the research. Member statuses are shown with stage subscription; their outcome reflects the reported membership state, not a payment.
• Hosted form returns in Authorize.Net (x_*) or Verisign (RESULT, PNREF) compatibility mode are not attributed to NETbilling unless an Ecom_Ezic_* field is present, and even then are not analyzed: NETbilling's encoding of their values is not documented.
• Data Retrieval Interface CSV reports, batch settlement CSV, Direct Mode Batch, Direct Mode 2.1 and Control CGI posts are not analyzed. Chargeback (dispute) data and recurring billing statuses exist only in those reports.
• The hosted form signature (Ecom_Ezic_ProofOfPurchase_MD5), request hashes, access keywords, 3ds_creq and card, bank and member credential fields are never copied or verified; a pasted postback is never treated as authentic.
• Categories: gateway and merchant account intermediary. NETbilling's NBCheck (ACH) underwriting is aggregation-like, but the research marks this as tentative and NETbilling does not call itself a payment facilitator, so it is not claimed.

Examples

• NETbilling: declined, insufficient funds: A form-encoded Direct Mode response; the decline is decoded from the whole authorization message.
• NETbilling: 3DS challenge pending: status_code=T with OFFLINE RECORD: nothing is authorized yet.

Provider documentation

• NETbilling documentation
• Direct Mode 3.2
• Transaction Authorization Message Definitions
• Test Mode Responses
• Payment Form 2.2
• Member Update Protocol 1.1
• Data Retrieval Interface 1.5

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