AI Security & Best Practices

AI tools accelerate development significantly — but in a payments context, moving fast without guardrails introduces real risk. The guidelines on this page help you get the benefits of AI-assisted development without exposing your credentials, your customers' data, or your production environment to unnecessary risk.

Credential Safety

⚠️

Never paste API keys, access tokens, or secret credentials into an AI chat interface. Most AI providers log conversations, and credentials shared in a chat may be stored, indexed, or exposed.

Rules to follow:

• Use environment variables for all credentials in AI-generated code. If the AI produces a hardcoded key in an example, replace it immediately.
• Use Stage credentials when working with AI during development and testing. Stage API keys are low-risk — they cannot move real money.
• If you accidentally share a Production API key in a chat session, rotate it immediately from the Localpayment Dashboard (https://ui.v3.localpayment.com for Production or https://ui.stage.localpayment.com for Stage) and audit your recent transaction history.
• Do not share webhook secrets, JWT tokens, or any authentication material in prompts, even in "sanitized" form that looks obvious.

Safe credential pattern in AI-generated code:

import os

# Always use environment variables — never hardcode credentials
API_KEY = os.environ["LOCALPAYMENT_API_KEY"]
BASE_URL = os.environ.get(
    "LOCALPAYMENT_BASE_URL", 
    "https://api.stage.localpayment.com"  # Default to Stage
)

Customer and Payment Data

Do not share real payment data with AI tools unless you have verified that the provider's data processing terms are compatible with your compliance obligations.

What to avoid pasting into AI chats:

• Real cardholder data (card numbers, CVVs, expiration dates)
• Real customer PII (national ID numbers, full names combined with document data)
• Real webhook payloads containing actual transaction amounts and account numbers from production
• Account numbers (CVU, CLABE, CCI) associated with real customers

What is safe:

• Sanitized or fictional webhook payloads (replace real values with placeholders like XXXX or example values)
• Error codes and status codes without the surrounding transaction context
• API request structures with example values from the documentation

Example — safe way to ask for webhook debugging help:

I'm receiving this webhook structure from Localpayment and I'm not sure 
how to parse the beneficiary fields. Here's a sanitized example:

{
  "externalId": "test-12345",
  "amount": 100,
  "beneficiary": {
    "bank": {
      "account": {
        "number": "0000000000000000000000"
      }
    }
  }
}

Which field identifies the virtual account that received the payment?

Stage Before Production

Always develop and test your AI-assisted integration against the Stage environment before deploying to Production.

ℹ️

The Localpayment MCP Server exposes documentation and API spec — it does not execute requests. All actual API calls happen in your own code, using your credentials. The environment risk depends entirely on which credentials and base URL you use in your integration.

Note that some features are only available in Production (for example, CVU alias creation in Argentina). The documentation for each feature explicitly notes when this applies.

Reviewing AI-Generated Code

AI-generated code should always be reviewed before merging or deploying. In a payments integration, errors can have financial consequences.

Checklist for reviewing AI-generated Localpayment integration code:

• No hardcoded credentials — all API keys use environment variables
• Correct base URL — Stage URL for development, Production URL for deployment
• externalId is unique — the code generates unique IDs per transaction (e.g., UUID). Duplicate externalIds will cause error 500.
• Webhook idempotency — the webhook handler checks whether the internalId has already been processed before acting
• HTTP 200 response — the webhook handler always returns 200 OK after processing, even for events it ignores
• HTTPS only — all API calls use HTTPS, never HTTP
• Error handling — rejected status codes (5xx, 8xx, 9xx) are caught and handled, not silently ignored
• Sensitive data not logged — API keys, card data, and customer PII are not written to logs

What Data Localpayment Can See

When you use any Localpayment AI tool (MCP Server, agent system prompts, or this documentation), it is important to understand exactly what Localpayment can and cannot access:

The Localpayment MCP Server is a read-only, public documentation server. It has no access to your Localpayment merchant account, transactions, or any data you have stored with Localpayment. It only serves the same documentation available publicly at https://docs.localpayment.com.

AI Tool Data Policies

Understanding how your AI provider handles the data you share is part of responsible use.

⚠️

Before using any AI tool to process customer or transaction data, you must evaluate your obligations under the data protection and financial regulations applicable to each country where you operate. The use of AI tools to process personal data, financial information, or payment transaction data may require specific legal bases, data processing agreements (DPA) with the AI provider, and technical safeguards depending on your jurisdiction.

Applicable regulations by country of operation include, but are not limited to:

• Argentina — Ley 25.326 de Protección de Datos Personales (LPDP) and applicable BCRA regulations
• Brazil — Lei Geral de Proteção de Dados (LGPD — Lei 13.709/2018)
• Colombia — Ley 1581 de 2012 (Habeas Data) and Decreto 1074 de 2015
• Mexico — Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) and its Reglamento
• Peru — Ley 29733 de Protección de Datos Personales and its Reglamento (D.S. 003-2013-JUS)
• Chile — Ley 19.628 sobre Protección de la Vida Privada (and amendments in force)
• Ecuador — Ley Orgánica de Protección de Datos Personales (LOPDP)
• All markets — PCI DSS v4.0 for any processing involving payment card data

In all cases: (1) verify that your AI provider has signed a Data Processing Agreement (DPA) covering the specific data types you intend to share; (2) apply data minimization — share only what is strictly necessary; (3) never share cardholder data, national IDs, or financial account numbers with any AI tool without explicit legal authorization and appropriate technical controls.

Quick Reference

Next Steps