Security and trust boundaries

Secrets and network path

The token does not pass through Rabet servers; the merchant environment sends it directly to the payment provider API. It is not placed in the Web Component or HTML. MCP runs over local stdio, and the core has no Rabet database and does not persist or log optional customer fields.

Restricted authority

create_payment_link requires the explicit confirm:true flag; otherwise it remains pending confirmation and makes no create call. The integrating client must obtain human approval before setting the flag, because the server checks a boolean and cannot prove human presence. No public MCP refund, capture, or payout tools exist. The UPayments client has an internal 25-request-per-minute guard; that is not a hosted-service quota or load-test result.

Project writes

rabet init previews by default. Apply mode writes only defined paths inside the Laravel root and does not overwrite an existing file. Still use Git and backups and review all eight generated files before running them.

Webhook trust boundary

Webhook content is not the source of truth. Generated code independently requests status from the gateway and accepts success only when it receives CAPTURED. This is status re-verification, not a claim that the message has a cryptographic signature.

Merchant responsibilities

• Server-side authentication, authorization, and amount, currency, and order-state calculation.
• Token protection and rotation, sandbox/production separation, and HTTPS.
• Runtime and dependency patching, provider configuration, and fraud controls.
• Logs, retention, incident response, privacy, and consumer obligations.

Security reporting

Report security issues to Info@almorshednet.com with “Security” in the subject; do not send tokens, card data, or customer data.

This page does not claim a certification, completed security audit, or guaranteed response time.