Архитектура платежного процессинга: от свайпа карты до взаиморасчетов

[chushpan]

Полное техническое руководство по устройству процессинговых центров и взаимодействию эмитентов с эквайерами в карточном бизнесе

Введение: почему эта архитектура имеет значение​

В мире, где ежесекундно совершаются сотни тысяч платежных операций, надежность и эффективность процессинговых систем определяют успех всего финансового сектора. Архитектура процессинга — это не просто техническая реализация, а стратегический актив банка, влияющий на скорость обслуживания клиентов, безопасность операций и конечную прибыльность карточного бизнеса.

Каждая транзакция стоимостью в несколько рублей проходит через сложную цепочку систем, каждая из которых должна работать безупречно. Понимание этой архитектуры необходимо не только IT-специалистам, но и руководителям бизнес-направлений, риск-менеджерам и всем, кто связан с платежной индустрией.

1. Базовые принципы и ролевая модель​

1.1 Ключевые участники платежной экосистемы​

Участник	Основная функция	Технологическая ответственность
Эмитент	Выпуск карт, управление счетами держателей	Авторизация транзакций, списание средств, риск-менеджмент клиентской стороны
Эквайер	Обслуживание торговых точек, прием платежей	Прием транзакций от терминалов, гарантия платежа мерчанту
Платежная система	Установление правил, маршрутизация, брендинг	Сеть передачи данных, клиринг, гарантия расчетов
Процессинговый центр	Технологическая обработка транзакций	Инфраструктура, программное обеспечение, интеграции
Мерчант	Прием платежей за товары/услуги	Терминальное оборудование, интеграция с эквайером
Держатель карты	Инициация платежей	Предъявление платежного средства

1.2 Модели организации процессинга​

А. Инсайдерский (in-house) процессинг

• Крупные банки (Сбер, ВТБ, Тинькофф)
• Полный контроль над технологиями
• Высокие CAPEX, но низкие OPEX на больших объемах
• Возможность быстрой кастомизации

Б. Аутсорсинговый процессинг

• Малые и средние банки
• Сервисная модель (pay-per-transaction)
• Быстрый запуск карточных продуктов
• Зависимость от провайдера

В. Гибридная модель

• Ядро — своё, периферия — аутсорсинг
• Например, свой эмитентский процессинг, но аутсорс эквайринга

2. Детальная архитектура процессингового центра​

2.1 Фронтальные системы и шлюзы​

Торговый (мерчант) шлюз

Назначение:
- Первичный прием транзакций от торговых точек
- Поддержка различных интерфейсов

Технические характеристики:
- Поддержка протоколов:
* ISO 8583 (финансовый стандарт)
* REST API / GraphQL (для e-commerce)
* WebSocket (для real-time уведомлений)
- Пропускная способность: от 1,000 до 50,000 TPS
- Средняя задержка: < 100 мс для 95% транзакций

Безопасность:
- PCI DSS Level 1 compliance
- TLS 1.3+ для всех соединений
- Регулярные penetration tests

Банкоматный шлюз

Особенности:
- Поддержка устройств различных вендоров: NCR, Diebold, GRG
- Протоколы: NDC/DDC, ISO 8583 с расширениями
- Управление наличностью (cash management)
- Интеграция с инкассаторскими службами

Функционал:
- Диспенсинг наличных
- Прием наличных (cash-in)
- Переводы между счетами
- Выписки и баланс
- Платежи в пользу третьих лиц

Шлюз мобильных приложений

Архитектурные паттерны:
- API Gateway (Kong, Apigee)
- Rate limiting и throttling
- Кэширование частых запросов (Redis)
- Circuit breaker pattern для устойчивости

Mobile-specific функции:
- Push-уведомления о транзакциях
- Биометрия для аутентификации
- Tokenization платежных данных
- Offline-режим с последующей синхронизацией

2.2 Ядро процессинга (Core Processing Engine)​

Авторизационный движок
Многоуровневая архитектура принятия решений:

1. Первичная валидация (10-20 мс)
   • Проверка формата сообщения
   • Валидация BIN/IIN карты
   • Проверка на дубликаты (idempotency check)
2. Бизнес-правила (30-50 мс)
   

   -- Пример правил в псевдокоде
   IF transaction.amount > card.daily_limit THEN REJECT
   IF transaction.country NOT IN card.allowed_countries THEN REJECT
   IF transaction.mcc IN restricted_categories AND time BETWEEN '00:00' AND '06:00' THEN REJECT

3. Риск-менеджмент (40-100 мс)
   • Статистические модели: средний чек, частота операций
   • Геолокационные аномалии: impossible travel detection
   • Поведенческий анализ: deviation from spending pattern
   • Списки мошеннических мерчантов и карт
4. Финансовые проверки (20-40 мс)
   • Доступный баланс/лимит
   • Кэшбэк-программы и бонусы
   • Валютные конвертации по правилам ЦБ

Система управления рисками (Fraud Detection System)
Современный подход — многослойная защита:

# Упрощенная архитектура FDS
class FraudDetectionSystem:
def analyze_transaction(self, transaction):
scores = {}

# 1. Rule-based engine
scores['rules'] = self.apply_business_rules(transaction)

# 2. Machine Learning models
scores['ml_models'] = {
'xgboost': self.xgboost_model.predict(transaction_features),
'neural_net': self.nn_model.predict(sequence_of_transactions),
'graph_analysis': self.analyze_transaction_graph(transaction)
}

# 3. External data sources
scores['external'] = {
'ip_reputation': self.check_ip_reputation(transaction.ip),
'device_fingerprint': self.analyze_device(transaction.device_id),
'biometric_confidence': transaction.biometric_score
}

# 4. Real-time consortium data
scores['consortium'] = self.query_fraud_consortium(transaction)

return self.aggregate_scores(scores)

Популярные решения на рынке:

• SAS Fraud Management
• IBM Safer Payments
• Featurespace ARIC
• Внутренние разработки крупных банков

2.3 Система баз данных и хранения​

Требования к производительности:

• Чтение: 95-й перцентиль < 10 мс
• Запись: 95-й перцентиль < 15 мс
• Доступность: 99.99% (менее 1 часа простоя в год)
• Репликация: синхронная в пределах дата-центра, асинхронная между ДЦ

Специализированные БД для разных задач:

Операционные данные (OLTP):
- Postgre[CODE=sql] с TimescaleDB extension для временных рядов
- Oracle Exadata для крупнейших игроков
- Google Spanner для глобальной распределенности

Кэширование:
- Redis Cluster: сессии, горячие данные, rate limiting
- Memcached: статический контент, справочники

Аналитика (OLAP):
- ClickHouse: реальная аналитика транзакций
- Apache Druid: агрегации для мониторинга
- Vertica: исторические данные для ML

Графовые БД:
- Neo4j или TigerGraph для анализа связей в мошеннических схемах

2.4 Клиринг и расчеты (Clearing & Settlement)​

Жизненный цикл транзакции:

graph LR
A[Авторизация] --> B[Блокировка средств];
B --> C[Завершение транзакции];
C --> D[Клиринг днём T];
D --> E[Сеттльмент T+1];
E --> F[Окончательное списание];

Процесс клиринга:

1. Подготовка файлов (18:00-23:00)
   • Формат: Visa CMS2, Mastercard MIP
   • Содержание: все завершенные транзакции за день
   • Криптографическая подпись файлов
2. Обмен между банками (23:00-02:00)
   • Через платежную систему (VisaNet, Banknet)
   • Peer-to-peer для прямых корреспондентских отношений
   • Автоматическое выявление и разрешение расхождений (reconciliation)
3. Сеттльмент (03:00-06:00)
   • Чистая позиция (net position) каждого банка
   • Проводки по счетам в ЦБ или коррсчетах
   • Уведомления о успешном расчете

Техническая реализация:

public class ClearingEngine {
public void processDailyClearing() {
// 1. Extract all finalized transactions
List<Transaction> transactions = transactionRepo
.findFinalizedSince(lastClearing);

// 2. Group by counterparty and payment system
Map<String, ClearingBatch> batches = groupTransactions(transactions);

// 3. Apply interchange fees and commissions
applyPricingRules(batches);

// 4. Generate standard format files
for (ClearingBatch batch : batches.values()) {
String fileContent = formatCMS2(batch);
String signature = hsm.sign(fileContent);
uploadToPaymentSystem(fileContent, signature);
}

// 5. Wait for responses and handle exceptions
monitorProcessingStatus();
}
}

3. Взаимодействие эмитента и эквайера: от запроса до ответа​

3.1 Полный цикл транзакции POS​

Шаг 1: Инициирование (0-100 мс)

# ISO 8583 Message Format (Simplified)
{
"MTI": "0200", # Message Type: Financial Request
"PAN": "526691******1234", # Primary Account Number
"ProcessingCode": "000000", # Purchase
"Amount": "000000010000", # 100.00 in minor units
"TransmissionDateTime": "0112101530",
"STAN": "123456", # Systems Trace Audit Number
"LocalTime": "101530",
"LocalDate": "0112",
"MerchantType": "5411", # MCC: Groceries
"POSEntryMode": "021", # Chip read
"POSConditionCode": "00", # Normal presentment
"Track2Data": "526691...=991200...",
"RRN": "123456789012", # Retrieval Reference Number
"MerchantId": "MERCH123456",
"TerminalId": "TERM001"
}

Шаг 2: Маршрутизация через платежную систему
Алгоритм выбора маршрута (routing logic):

def route_transaction(transaction):
# 1. По BIN определяем платежную систему
bin_prefix = transaction.pan[:6]
payment_system = bin_table.lookup(bin_prefix)

# 2. Для локальных карт - прямой маршрут
if payment_system == 'LOCAL':
if transaction.acquirer == transaction.issuer:
return 'ON_US' # Внутренняя транзакция
else:
return 'DOMESTIC_SWITCH' # Национальный коммутатор

# 3. Для международных карт - через международную ПС
elif payment_system == 'VISA':
return 'VISANET'
elif payment_system == 'MASTERCARD':
return 'BANKNET'

# 4. Fallback маршруты
return select_best_route_based_on_cost(transaction)

Шаг 3: Авторизация у эмитента
Критически важные проверки:

1. Валидация карты
   • Существует ли карта в базе?
   • Не истек ли срок действия?
   • Не заблокирована ли (hot card)?
2. Проверка счета
   

   -- Пример [CODE=sql] запроса для проверки баланса
   SELECT
   a.current_balance,
   a.available_balance,
   c.daily_limit,
   c.daily_spent,
   CASE
   WHEN a.available_balance >= :amount
   AND (c.daily_limit - c.daily_spent) >= :amount
   THEN 'APPROVE'
   ELSE 'DECLINE'
   END as decision
   FROM accounts a
   JOIN cards c ON a.account_id = c.account_id
   WHERE c.card_number_hash = :card_hash
   AND c.expiry_date >= CURRENT_DATE
   AND c.status = 'ACTIVE';

3. Сложные продукты и лимиты
   • Кредитные карты: available credit vs. utilized amount
   • Дебетовые карты: баланс + овердрафт
   • Предоплаченные: остаток на карте
   • Виртуальные карты: merchant/transaction-specific limits

Шаг 4: Генерация ответа

{
"MTI": "0210", # Financial Response
"ActionCode": "000", # Approved
"AuthorizationCode": "A1B2C3", # 6-char code from issuer
"ResponseCode": "00", # Success
"HostResponseCode": "000", # Issuer specific
"TransactionId": "TX987654321",
"AdditionalData": {
"available_balance": "1500.00",
"loyalty_points_earned": "10",
"dynamic_cvv": "123" # Для цифровых карт
}
}

3.2 Специфические типы транзакций​

Онлайн-транзакции (e-commerce)

Особенности:
- 3-D Secure 2.x обязателен для SCA (Strong Customer Authentication)
- Tokenization вместо PAN
- Recurring payments для подписок

Поток данных:
1. Merchant → Acquirer: Auth request with 3DS data
2. Acquirer → Directory Server: Check enrollment
3. Directory Server → Issuer: Authentication request
4. Issuer → Cardholder: Frictionless/Challenge flow
5. Cardholder → Issuer: Authentication response
6. Issuer → Acquirer: Auth response with CAVV
7. Acquirer → Merchant: Final result

Транзакции с отложенной авторизацией
Используются в:

• АЗС (авторизация на 1 рубль, клиринг на фактическую сумму)
• Отелях (блокировка депозита)
• Аренде автомобилей

-- Механизм двухэтапной авторизации
-- Этап 1: Pre-authorization
INSERT INTO authorizations (id, card_id, amount, type, status)
VALUES ('AUTH123', 'CARD001', 100.00, 'PREAUTH', 'PENDING');

-- Этап 2: Completion (может быть через несколько дней)
UPDATE authorizations
SET completion_amount = 85.50,
status = 'COMPLETED',
completed_at = NOW()
WHERE id = 'AUTH123';

4. Инфраструктурные аспекты​

4.1 Требования PCI DSS для процессинговых центров​

Уровень 1 (более 6 млн транзакций в год):

• Ежеквартальные сканирования уполномоченным ASV
• Годовой аудит QSA (Report on Compliance)
• Внутренние сканирования уязвимостей
• Файрволлы между всеми сегментами сети

Ключевые меры безопасности:

Шифрование данных:
- PAN в rest: AES-256 с HSM-managed keys
- PAN in transit: TLS 1.3+ с perfect forward secrecy
- Key rotation: каждые 90 дней для encryption keys

Контроль доступа:
- Role-based access control (RBAC)
- Multi-factor authentication для админ-доступа
- Полное логирование всех действий

Сетевой периметр:
- Сегментация: CDE (Cardholder Data Environment) отдельно
- IDS/IPS системы
- WAF для web-интерфейсов

4.2 Обеспечение высокой доступности​

Геораспределенная архитектура:

Основной ДЦ (Москва):
- Active-active кластер баз данных
- Авторизационный движок (основной)
- Шлюзы платежных систем

Резервный ДЦ (Санкт-Петербург):
- Hot standby реплики БД
- Авторизационный движок (резервный)
- Минимальный набор шлюзов

Дизайн на отказ:
- Automatic failover при потере связи с основным ДЦ
- Межрегиональная репликация с RPO < 5 секунд
- Регулярные disaster recovery тесты

Паттерны resilience:

// Circuit Breaker для внешних вызовов
@CircuitBreaker(
name = "visaGateway",
failureRateThreshold = 50,
waitDurationInOpenState = 30000,
slidingWindowSize = 100
)
public AuthorizationResponse callVisaNetwork(AuthorizationRequest request) {
return visaClient.authorize(request);
}

// Bulkhead для изоляции ресурсов
@Bulkhead(name = "hsmOperations", type = SEMAPHORE, value = 10)
public String signWithHSM(String data) {
return hsmClient.sign(data);
}

// Retry с экспоненциальной backoff
@Retry(name = "databaseRetry",
maxAttempts = 3,
backoff = @Backoff(delay = 100, multiplier = 2))
public Account getAccount(String accountId) {
return accountRepository.findById(accountId);
}

4.3 Мониторинг и observability​

Ключевые метрики:
prometheus:

# Пропускная способность
payment_transactions_total{type="authorization", status="success"} 1000
payment_transactions_rate{gateway="pos"} 150.5 # транзакций/секунду

# Задержки
payment_processing_duration_seconds{quantile="0.95"} 0.245
authorization_response_time_seconds{issuer="bank_a"} 0.156

# Доступность
service_up{component="core_processor"} 1
database_connections_available 45

# Бизнес-метрики
authorization_approval_rate 97.5
chargeback_rate 0.015 # 1.5 базисных пункта

Стэк технологий для мониторинга:

• Метрики: Prometheus + VictoriaMetrics
• Логи: ELK Stack (Elasticsearch, Logstash, Kibana) или Loki
• Трейсинг: Jaeger или Zipkin для распределенных транзакций
• Визуализация: Grafana с business-friendly дашбордами

5. Тренды и будущее архитектуры процессинга​

5.1 Сдвиг к облачным и гибридным моделям​

Современный подход:
- Чувствительные данные (PAN, ключи) в приватном контуре
- Вычислительные нагрузки (ML для fraud detection) в облаке
- Kubernetes для оркестрации микросервисов

Пример архитектуры:
components:
on_premise:
- HSM для криптоопераций
- Ядро БД с данными карт
- PCI DSS контроллеры

cloud_public:
- AI/ML модели для анализа рисков
- Хранилище логов и аналитики
- CDN для статического контента

5.2 Open Banking и API-экономика​

PSD2 и аналогичные регуляции требуют:

1. API для доступа третьих сторон
   • Информационные API (балансы, транзакции)
   • Платежные инициации (payment initiation)
   • Подтверждение доступности средств
2. Архитектурные изменения
   

   # Open Banking Gateway
   class OpenBankingGateway:
   def __init__(self):
   self.validators = [
   TPPCertificateValidator(), # Проверка сертификата TPP
   ConsentValidator(), # Наличие действующего согласия
   RateLimiter(), # Ограничения по количеству вызовов
   PSUAuthenticationValidator() # Аутентификация конечного пользователя
   ]
   
   def process_request(self, request, tpp_id):
   # Валидация всех аспектов
   for validator in self.validators:
   validator.validate(request, tpp_id)
   
   # Маршрутизация к внутренним системам
   return self.route_to_backend(request)

5.3 Real-time процессинг и мгновенные платежи​

Технологические требования для instant payments:

• End-to-end время обработки < 3 секунд
• 24/7/365 доступность
• Finality of payment: безвозвратность после исполнения

Архитектурные паттерны:

• Event-driven architecture с Apache Kafka или RabbitMQ
• In-memory computing (Hazelcast, Apache Ignite)
• Stream processing (Apache Flink, Kafka Streams)

5.4 Искусственный интеллект и машинное обучение​

Применение в процессинге:

1. Predictive авторизация
   

   # Предсказание вероятности успешной транзакции
   class PredictiveAuthEngine:
   def predict_approval_probability(self, transaction):
   features = self.extract_features(transaction)
   
   # Модель учитывает:
   # - Историческое поведение клиента
   # - Сезонность и время суток
   # - Поведение в подобных MCC
   # - Глобальные паттерны мошенничества
   
   probability = self.model.predict(features)
   
   if probability > 0.95:
   return "APPROVE_WITHOUT_RISK_CHECK"
   elif probability > 0.7:
   return "STANDARD_AUTH_FLOW"
   else:
   return "ENHANCED_FRAUD_SCREENING"

2. Динамическое ценообразование
   • Real-time вычисление interchange fees
   • Персонализированные кэшбэк-программы
   • Прогнозирование доходности транзакций

Заключение: проектирование процессинга будущего​

Архитектура процессинговых центров эволюционирует от монолитных, жестко связанных систем к гибким, API-ориентированным платформам. Ключевые принципы современного проектирования:

1. Модульность и микросервисы — возможность независимого масштабирования и обновления компонентов
2. Резильентность — устойчивость к отказам внешних систем и внутренних компонентов
3. Безопасность по дизайну — встроенные механизмы защиты, а не навесные решения
4. Observability — полная прозрачность работы системы для быстрого выявления проблем
5. Реальное время — способность обрабатывать и анализировать данные в потоковом режиме

Успешная архитектура платежного процессинга сегодня — это не просто технологическая платформа, а стратегический инструмент, позволяющий банкам быстро запускать новые продукты, адаптироваться к меняющимся регуляторным требованиям и предоставлять клиентам беспрерывный, безопасный сервис в мире, где платежи становятся все более невидимыми и интегрированными в повседневную жизнь.

Автор: Архитектор платежных систем
Для использования в образовательных целях. Реальные архитектуры могут отличаться в зависимости от конкретного банка, объема транзакций и регуляторных требований.