How do you check if a Cardcom v11 transaction succeeded?

Check ResponseCode == 0. The DealResponse field used in many older examples and libraries does not exist in v11, so code checking it receives undefined and produces the wrong verdict. Every v11 endpoint also returns a Description string explaining the outcome, which is worth logging on success as well as failure.

Should I mark an order paid on the Cardcom redirect or the webhook?

The webhook. The browser redirect depends on the customer staying on the page - anyone who closes the tab after paying never reaches your success URL, leaving an order marked pending while the money was taken. Use WebHookUrl to update order state and the redirect only to show a thank-you screen, and make the webhook endpoint idempotent since notifications can repeat.

What document type codes does Cardcom v11 use?

String enums such as "TaxInvoiceAndReceipt", "TaxInvoice" and "Receipt" in the DocumentTypeToCreate field. The numeric codes like 101 or 400 that appear in many examples belong to the older .aspx interfaces and will not work against v11. Sending a number where the string enum is expected produces a validation failure.

How do I link a Cardcom payment back to my own order?

Use the ReturnValue field, which is a free-text field returned to you verbatim - put your order id in it. Also store the LowProfileId returned by the Create call on your order record. Between the two you can reconcile any payment against your own data without manual comparison.

Does using Cardcom LowProfile put me in PCI DSS scope?

The point of LowProfile is that card details are entered on Cardcom's page and never pass through your server, which keeps your scope minimal. That protection only holds if you never send, log or store card data yourself. The moment card details touch your system - even in a log line - the picture changes.

Cardcom API v11 Guide - Yehonatan Saadia

A developer's guide to the Cardcom LowProfile v11 API - the Create endpoint, why ResponseCode is the only success check, the string document enums that replaced legacy numeric codes, and why the webhook rather than the redirect is your source of truth.

Cardcom is one of the long-established Israeli payment gateways, and its LowProfile interface is the common way to take a payment from a website or system: you create a payment page, send the customer to it (or embed it in an iframe), and the card processing happens on Cardcom's side - so card details never pass through your server at all.

This guide covers v11, and the differences between it and the older interfaces are exactly where integrations fall over.

Creating a payment page

The call is:

POST https://secure.cardcom.solutions/api/v11/LowProfile/Create

The main body fields:

TerminalNumber - the terminal number. Must be sent as an integer, not a string.
ApiName - the API username
Operation - what to do: charge only, create a token, or both
Amount and ISOCoinId - amount and currency
ReturnValue - the most useful field in practice. A free field returned to you verbatim. Put your order id in it.
SuccessRedirectUrl and FailedRedirectUrl - where the browser is sent
WebHookUrl - where Cardcom notifies your server
Language
Document - an optional object for issuing a document automatically

The response returns LowProfileId - store it on the order - and Url, which you redirect to or embed in an iframe. If Bit or PayPal are enabled on the terminal, UrlToBit and UrlToPayPal come back too.

Three v11 traps behind most failures

1. ResponseCode, not DealResponse

This is the costly one. In v11 you check success with ResponseCode == 0. The DealResponse field, which appears in countless web examples and older libraries, does not exist in v11 at all.

Code checking a non-existent field receives undefined or null, and its comparison fails - so success reads as failure, or the reverse, depending on how the check was written. This is precisely the class of bug that passes testing and detonates in front of a customer.

Every endpoint also returns a Description string explaining the outcome. Log it always, including on success.

2. Document types are strings, not numbers

If you ask Cardcom to issue a document automatically, the DocumentTypeToCreate field in v11 is a string enum: "TaxInvoiceAndReceipt", "TaxInvoice", "Receipt" and so on.

The numeric codes you may find in examples - 101, 400 and friends - belong to the older .aspx interfaces, not v11. Sending a number where a string is expected will fail.

3. ApiPassword is not sent on a normal call

ApiPassword is not sent on a standard LowProfile/Create or a standard transaction charge. If you added it because you saw it somewhere, check the documentation for which operation actually requires it - sending superfluous fields is an easy route to a confusing validation error.

The architectural decision: webhook or redirect

There are two channels through which you learn a payment succeeded, and choosing between them determines how many orders quietly "vanish".

	Browser redirect	WebHookUrl
Arrives via	The customer	Cardcom's server directly
Always happens?	No	Yes
Depends on	The customer not closing the tab	Nothing

The redirect is not reliable. A customer who closes the browser the instant the payment clears, whose connection drops, or who simply does not wait, never reaches your SuccessRedirectUrl. If that is where you mark the order paid, the order stays "pending" while the money has been taken. This happens, and it looks like a random bug.

The rule: the webhook updates order state. The redirect shows the user a thank-you screen. Never the other way round.

And the webhook endpoint must be idempotent regardless - the same notification can arrive more than once, and that must not produce two paid orders.

The second decision: who issues the document

Cardcom can issue a document automatically through the Document object. That is convenient - but if your system also issues an invoice through your invoicing system, one transaction ends up with two tax documents.

This is the most common design mistake when payments and accounting land in the same project, and it surfaces at month end. Pick one side and write it down.

Security and compliance

Do not touch card details. The entire point of LowProfile is that they never pass through you. Do not send them, log them or store them - doing so pulls you into PCI DSS scope.
Authenticate the webhook. A public endpoint that marks orders paid is an obvious target. Do not rely on the URL being secret - validate the request and cross-check the amount against the order.
Cross-check amounts. Always confirm the returned amount matches what you asked for. Do not assume nobody tampered with the request.
Server-side secrets only. ApiName and terminal details never appear in client code.

Before going live

Confirm your terminal is actually on v11 and enabled for LowProfile.
Test the webhook path end to end, not just the redirect.
Explicitly test the case where the customer closes the tab right after paying.
Decide whether Document applies to you, and confirm there is no double issuance.
Test a real failure, not only success - FailedRedirectUrl and a non-zero ResponseCode.

For a comparison of the Israeli gateways, see Israeli payment gateways compared.

Cardcom API v11: Taking Payments From Your Own System

Key takeaways