Security

The integration handles client credentials, bearer tokens, taxpayer identity data, addresses, contact information, transaction details, and official document identifiers. Apply controls appropriate to confidential financial and personal data.

Client secrets

  • Store the client secret in a managed secret store or protected operating-system credential facility.
  • Inject it at deployment or runtime; do not compile it into an application.
  • Never commit it to source control, including private repositories.
  • Do not place it in configuration examples, screenshots, diagnostic bundles, or chat messages.
  • Restrict read access to the integration service identity and authorized operators.
  • Rotate immediately if it appears in source code, logs, email, or another uncontrolled location.

Bearer tokens

Treat an access token as a temporary credential. Keep it in memory or an encrypted cache, never in a URL. Redact the Authorization header from logs and tracing systems.

Transport

  • Use HTTPS only.
  • Validate the server certificate and hostname.
  • Do not disable certificate validation to make sandbox testing pass.
  • Set connection and response timeouts.
  • Keep TLS libraries and root certificates supported and current.

Data minimization

Send only fields required for the e-Invoice and business process. Avoid putting unrelated notes, credentials, payment-card data, or secret internal values in free-text descriptions or cancellation reasons.

Mask or omit from ordinary logs:

  • client ID and client secret;
  • bearer token;
  • full TIN and identification number;
  • names, telephone numbers, email addresses, and street addresses;
  • raw JSON payload;
  • QR custom GUID when it can open a customer receipt link;
  • accepted UUID and long ID when combined into a public document link.

Use a controlled diagnostic store with limited access and retention when a full payload is genuinely required for investigation.

Authorization and separation of duties

Limit submission to the merchant's integration service. Restrict voiding, cancellation, credential regeneration, and production configuration to specifically authorized roles. Record who approved and initiated each destructive document action.

Source-system controls

  • Authenticate the POS or ERP process that generates a document.
  • Prevent unauthorized modification after approval.
  • Use a cryptographically strong random value for qr_custom_guid.
  • Maintain an audit link from the source record to the AECloud sale GUID.
  • Protect retry queues from manual payload substitution.
  • Validate all external input before constructing JSON.

Incident response

If a credential may be exposed:

  1. stop unauthorized use where possible;
  2. regenerate the merchant API credential through an approved process;
  3. update every legitimate consumer;
  4. review authentication and submission activity;
  5. check for unexpected documents or state changes; and
  6. document the incident and remediation.

For urgent assistance, contact support@einvoicecloud.com through the approved support channel without sending the exposed secret.