Payment boundary: The Silvatech checkout sends customers to a supported bank-hosted card page for card entry. This policy does not replace the merchant's or bank's own privacy notice.
1. Information the service processes
Depending on the integration, Silvatech Payments can process merchant and tenant configuration, payment amount and currency, order and customer references, descriptions, return and callback URLs, payment status, bank-provided transaction references, timestamps, and operational history.
When supplied for a checkout, receipt, reminder, saved-card, or subscription workflow, the service can also process a customer's name, email address, phone number, merchant customer reference, masked card details, card brand, expiry information, and a token or binding identifier returned by the supported gateway.
Technical records can include IP address, user agent, endpoint, request identifier, response status, timing, security events, and callback or gateway data needed to operate, troubleshoot, and reconcile the integration. Merchants control optional descriptions and metadata and should not place unrelated sensitive information in those fields.
2. How information is used
Information is used to initialize and verify payments, operate hosted checkout and payment links, run consent-based subscriptions, send configured transactional notifications, deliver or receive callbacks, support refunds and reversals, secure tenant access, investigate failures, and maintain auditable operational records.
The public site can load Silvatech-hosted Rybbit analytics when analytics is enabled. It records website usage such as page views and tracked ecosystem-link interactions so Silvatech can understand which public pages and product handoffs are useful.
3. When information is shared
Payment instructions and results are exchanged with the merchant's configured bank gateway. Status and callback data can be sent to the merchant application endpoint configured for the integration. Service data is processed on infrastructure used to host, monitor, back up, and secure the application, including Amazon Web Services for the current production deployment.
Information may also be disclosed when required by a valid legal process or when reasonably necessary to investigate abuse, protect the service, or protect affected users. Silvatech does not publish or sell customer payment records as a marketing list.
4. Card information
The public Silvatech checkout does not ask customers to type a full card number or security code into a Silvatech form. Card entry takes place on the supported bank-hosted page. The gateway can return a token or binding identifier and masked card information for an authorized saved-card or recurring-payment workflow.
Do not send full card numbers, security codes, banking passwords, or gateway credentials through descriptions, metadata, callback fields, email, or support requests.
5. Retention and security
Records are retained for as long as needed to operate and secure the service, reconcile payment activity, support the merchant relationship, resolve disputes, and meet applicable contractual or legal requirements. A universal public retention schedule is not currently promised; integration-specific requirements should be agreed in writing.
Silvatech uses HTTPS, access controls, tenant scoping, server-side secret storage, logging safeguards, backups, and restricted infrastructure access. No certification or audit status is claimed by this policy.
6. Cookies and public analytics
Authenticated surfaces can use essential cookies for sessions and request security. Public analytics is provided by the configured Rybbit service. Browser controls can limit cookies, but doing so may prevent authenticated features from working correctly.
7. Questions and requests
To ask what information is associated with an integration, request a correction, or raise a privacy concern, use the Silvatech contact page. Silvatech may need to verify the requester and coordinate with the responsible merchant or bank before acting on a request.
Silvatech may update this policy as the product and its data practices change. The date above will be revised when the published policy changes.