Verotel

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by type, event, saleID and transactionID for FlexPay postbacks that carry a transactionID, or trn and trn_id for VerotelRUM add and rebill (Verotel documents no event or delivery id).
• Delivery order: not documented by the provider.
• Make the postback handler idempotent per saleID, event and transactionID, and answer HTTP 200 with body OK within 30 seconds: for card payments an unanswered FlexPay postback triggers an automatic refund.

Known limitations

• FlexPay postbacks are HTTP GET requests whose data is in the URL query string. Paste the raw request, the full URL or just the query string; the host and path are not used for detection.
• Verotel publishes no literal FlexPay postback example; the adapter follows the documented v4 field tables. A success redirect copied from the browser carries the same fields as the initial or purchase postback and is not distinguished from it.
• Postbacks carry no timestamp and no event id. Events from postbacks have no event time; their order is the order of the supplied records, and nextChargeOn / expiresOn are shown as attributes only.
• Duplicate deliveries are recognized only for postbacks that carry a transactionID (rebill, credit, chargeback, and purchase, initial and upgrade with postbacks version 2) and for VerotelRUM add and rebill. Retry behavior for FlexPay postbacks is not documented. extend, downgrade, cancel, uncancel and expiry postbacks have no reliable delivery key, so repeated copies are not flagged.
• Declined payments and declined rebills produce no postback. A declined rebill can only show up indirectly as extend (Rebill-retry) followed by rebill or expiry. Declines are visible only in Control Center API transactions (is_approved=false with decline_reason).
• The expiry postback carries no reason, and extend does not say whether it was a manual extension or a Rebill-retry extension. Whether an expiry also follows a credit or chargeback is not documented.
• Verotel publishes no card decline code table. Only the decline category NO_FUNDS is documented; any other decline_reason is reported with insufficient confidence.
• For an initial postback with a trial, the amount shown is trialAmount (the first charge); priceAmount is kept as the recurring price attribute. A downgrade's amount is the new rebill price, not a charge, so it is not shown as an event amount.
• Chargeback postbacks and transactions are shown with stage dispute and an unknown outcome: the payload does not say whether the chargeback is final.
• transaction_subtype meanings (ONETIME, WALLET, PURCHASE, INITREC, RECURRED, CREDIT, CHBACK) and most API payment_method codes are not documented; the raw values are shown without interpretation.
• transactionID on initial, purchase and upgrade postbacks requires 'postbacks version 2', which is enabled in the Control Center; without it these postbacks link to later reversals only through saleID.
• VerotelRUM trn_id is kept in its own namespace: whether it equals the Control Center transaction id, or stays the same across commands of one membership, is not documented.
• Signatures (SHA-256 for FlexPay v4, SHA-1 for older versions) are never verified or copied; only their presence and length class are shown. A pasted postback is never treated as authentic.
• Control Center API error titles are matched leniently (published typo 'Paramter', optional final period). HTTP 404 and the 5000-record cap have no published title. Published API examples contain '=>' and are not valid JSON; such copies cannot be parsed and must be corrected first.
• The FlexPay status page is read as one snapshot of the sale, not as a notification: it has no delivery key, and repeated lookups of the same sale are not reported as separate events. Only saleResult APPROVED is documented; a missing or other saleResult leaves the outcome unknown. Subscription facts (type, phase, expired, cancelled, cancelledBy, period, trialPeriod, dates) are shown as attributes, not as lifecycle stages.
• Status page dates are never used as event times: createdOn is when the sale was created, not when the page was fetched, and v3 dates (dd-mmm-yyyy hh:mm:ss) carry no time zone. They are shown as attributes only.
• On a subscription status page priceAmount is the recurring price, not a charge, so it is shown as an attribute (with trialAmount and discountAmount) and not as the event amount. Only a purchase status page shows priceAmount as the amount.
• Status page NOTFOUND is decoded as an invalid request and ERROR as unknown; Verotel documents no values for the free-text error line, which is shown scrubbed and cut to 200 characters. A page with only the response line is read only as a raw HTTP response with Content-Type text/plain, and because one line does not identify Verotel it is analyzed only when Verotel is selected manually; pasted alone, one line is not read as name: value text.
• FlexPay request URLs (startorder, cancel-subscription, status request) are recognized but not analyzed.
• Buyer data (name, email, address, billingAddr_* lines, IP, country), custom1..3, description, truncatedPAN, masked identifiers, oneClickToken, usercode and passcode are never copied.
• An unanswered or non-OK postback acknowledgement leads Verotel to refund a card payment automatically (VerotelRUM: after two more attempts within 20 minutes); the supplied postback alone cannot show whether it was acknowledged.

Examples

• Verotel: subscription postbacks: Initial, rebill and cancel postbacks for one subscription, one per line.
• Verotel: subscription chargeback: A FlexPay chargeback postback linked to its sale.

Provider documentation

• FlexPay documentation (version 4)
• FlexPay purchase and postbacks
• FlexPay subscription and postbacks
• Control Center API
• VerotelRUM description
• FlexPay API v3 description (legacy)
• FlexPay subscription upgrade
• Integration overview

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