What Sikka receives. What it never receives.
| Receives |
|---|
| Merchant descriptor and MCC |
| Amount, currency, channel, time |
| The eligible card set, as product names |
| Objective and policy configuration |
| Never receives |
|---|
| PAN or any card number, full or partial |
| CVV, PIN, OTP, expiry |
| Credentials, tokens, bank logins |
| Cardholder identity or contact data |
The decision needs to know which products are in play, never the instruments themselves. The request is complete without a single sensitive field.
Stateless by construction.
The decision call is stateless: nothing about a request is required for the next one, and the live demo stores zero records. In a shadow pilot, decision and outcome logs exist for one purpose: attributing outcomes to decisions so accuracy can be measured. Retention, residency and access for those logs are agreed with your security team in the pilot workshop before anything runs.
Sikka does not authorize, clear or settle.
Not a gateway. Not a processor. Not payment execution. Sikka returns a recommendation before authorization; your processor remains authoritative over every payment outcome. The first deployment is shadow mode: a copy of transaction context is scored and compared against actual outcomes, and nothing returns to the authorization path.
Designed to fail out of the way.
Bounded timeout budget, configured fallback (customer_default), abstain over guess, and execution independence: if Sikka is slow, wrong-footed or down, your stack behaves exactly as it did before Sikka existed. There is no state in the decision layer that execution depends on.
Every decision can explain itself.
The engine is deterministic: same input, same rulebook, same configuration, same decision: replayable on demand. Every response carries its reason; the proposed production contract adds decision_id, machine-stable reason_code and rulebook_version so any decision can be traced to the exact rules that produced it. FULL TRACE · PROPOSED
One module. Your perimeter, if you want it.
The engine is a stateless module with no external calls at decision time, and it can be hosted inside your perimeter. The rulebook ships versioned and freshness-checked. Integration is one API in front of the stack: nothing in the execution path is replaced.
Workshop items, stated as workshop items.
Residency, controller and processor roles, retention, isolation, the deployment perimeter and PCI treatment are agreed with your security team and your QSA in the pilot workshop. We state that plainly instead of pre-declaring certifications: the honest sequence is scope first, attest second.