Cómo aplicar SRP en un procesador de pagos con Stripe

Curso de Patrones de Diseño y SOLID en Python

Contenido del curso

Patrones de Diseño y Principios SOLID

1
Patrones de diseño y SOLID en Python
02:07 min

Principios SOLID

Reestructuración del proyecto

13
Reestructuración con módulos de Python y SOLID
13:32 min

Patrones de Diseño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0025:19

Cómo aplicar SRP en un procesador de pagos con Stripe

Curso de Patrones de Diseño y SOLID en Python

Clase 4 de 27

Clase 4 / 27

Recursos

Aplicar el principio de responsabilidad única (SRP) en Python con Stripe no solo ordena el código: también hace el flujo de cobro más claro, testeable y mantenible. Aquí verás cómo se pasó de un PaymentProcessor monolítico a un diseño con validadores, servicio orquestador y componentes dedicados para notificación y registro, usando data class, type hints y manejo de excepciones.

¿Qué problema resuelve el principio de responsabilidad única en este procesador de pagos?

Separar responsabilidades evita que una clase haga de todo: validar, cobrar, notificar y loguear. El punto de partida fue un procesador rudimentario que incumplía SOLID. Se reorganizó con clases específicas: CustomerValidation, PaymentDataValidator, Notifier, TransactionLogger y un StripePaymentProcessor, coordinadas por PaymentService.

Importaciones y entorno al inicio del archivo: organización estándar de la industria.
PaymentProcessor como data class: instanciación simple sin definir init manual.
processTransaction con type hints: retorna una instancia de Stripe Charge.
Validaciones con excepciones: ValueError en lugar de objetos vacíos.
Corrección de flujo: si no hay email ni teléfono, igual se devuelve el charge exitoso.

¿Cómo estaba el código antes y qué ajustes iniciales se hicieron?

Importaciones y variables de entorno (por ejemplo, stripe_api_key) movidas al inicio.
PaymentProcessor convertido en data class para simplificar instanciación.
Firma de processTransaction conservada, ahora con retorno tipado a Charge.
Validaciones reemplazadas por raise ValueError con mensajes claros.
Bug corregido: ausencia de email y teléfono ya no corta el flujo; se devuelve el cargo igualmente.

¿Cuáles responsabilidades se identifican y por qué separarlas?

Validación de customer: nombre y contact info correctos.
Validación de pago: existencia de source en payment_data.
Procesamiento del pago: interacción con la librería de Stripe.
Notificación: por email o SMS, comportamiento moqueado.
Registro en logs: persistir contexto del cargo.

Separarlas permite que cada clase cambie por razones únicas, cumpliendo SRP.

¿Qué clases nuevas encapsulan cada responsabilidad?

CustomerValidation con validate(customer_data).
PaymentDataValidator con validate(payment_data).
Notifier con sendConfirmation(customer_data) para email o teléfono.
TransactionLogger con log(customer_data, payment_data, charge).
StripePaymentProcessor (renombrado para ser semántico) con processTransaction(...).
PaymentService como orquestador.

Ejemplo de estructura mínima:

from dataclasses import dataclass

class CustomerValidation:
    def validate(self, customer_data: dict) -> None:
        if not customer_data.get("name"):
            raise ValueError("missing name")
        if not customer_data.get("contact_info"):
            raise ValueError("missing contact info")

class PaymentDataValidator:
    def validate(self, payment_data: dict) -> None:
        if "source" not in payment_data:
            raise ValueError("missing source")

class Notifier:
    def sendConfirmation(self, customer_data: dict) -> None:
        if customer_data.get("email"):
            print("enviar email moqueado.")
        elif customer_data.get("phone"):
            print("enviar sms moqueado.")

class TransactionLogger:
    def log(self, customer_data: dict, payment_data: dict, charge):
        print(f"pagó {payment_data['amount']} la persona {customer_data['name']}")

¿Cómo coordina PaymentService el flujo con validadores, processor y notificaciones?

PaymentService concentra el flujo: valida datos, procesa con StripePaymentProcessor, notifica con Notifier y registra con TransactionLogger. Devuelve el Charge de Stripe y propaga stripe_error si algo falla. Se usa try/except para manejar ValueError ya emitidos por los validadores.

@dataclass
class PaymentService:
    customer_validator: CustomerValidation
    payment_validator: PaymentDataValidator
    stripe_payment_processor
    notifier: Notifier
    transaction_logger: TransactionLogger

    def processTransaction(self, customer_data: dict, payment_data: dict) -> "Charge":
        try:
            self.customer_validator.validate(customer_data)
        except ValueError as e:
            raise e

        try:
            self.payment_validator.validate(payment_data)
        except ValueError as e:
            raise e

        try:
            charge = self.stripe_payment_processor.processTransaction(customer_data, payment_data)
        except stripe_error as e:
            raise e

        self.notifier.sendConfirmation(customer_data)
        self.transaction_logger.log(customer_data, payment_data, charge)
        return charge

¿Qué cambio clave evita errores en las validaciones?

En lugar de if esperando booleanos, los validadores ya hacen raise ValueError. Por eso, en PaymentService se usa try/except y se re-lanza la misma excepción. Esto elimina falsos positivos de validación y simplifica el control de flujo.

try:
    customer_validator.validate(customer_data)
except ValueError as e:
    raise e

¿Qué se corrige en notificaciones y retorno del cargo?

Si no hay email ni phone, el flujo continúa y se retorna el charge exitoso.
La notificación es moqueada: impresión por consola según disponibilidad de contacto.
El logger persiste contexto: monto (p. ej., 500 o 700) y nombre (p. ej., John Doe).

¿Cómo se maneja un fallo de Stripe con tokens de prueba?

Se reproducen fallos con token de riesgo como “radar block”: la tarjeta es declinada por defecto.
El StripePaymentProcessor levanta la excepción capturada; PaymentService la propaga.
En el código cliente, se puede envolver la llamada en try/except y reportar: “falló el procesamiento: {error}”.

try:
    charge = payment_service.processTransaction(customer_data, payment_data)
except Exception as e:
    print(f"falló el procesamiento: {e}")

¿Qué habilidades y conceptos aplicas al refactor bajo SOLID?

Refactorizar con SRP exige precisión y criterio. Aquí se aplican prácticas de alto impacto para código de pagos en producción.

SRP (principio de responsabilidad única): cada clase cambia por una razón única.
Orquestación con PaymentService: coordina validación, cobro, notificación y logging.
Renombramiento semántico: StripePaymentProcessor refleja su dominio real.
Python data class: instanciación clara, sin __init__ explícito.
Python type hints: processTransaction -> Charge mejora legibilidad y contratos.
Manejo de excepciones: ValueError en validaciones; propagación de stripe_error.
Mocks funcionales: envío de email/SMS como impresión controlada.
Corrección de flujo: retorno del charge aunque no haya medios de contacto.
Depuración con debugger y breakpoints: verificación de estados intermedios.
Pruebas de error con tokens de Stripe: “radar block” simula tarjeta declinada.

¿Tú cómo separarías aún más las responsabilidades o qué cambios harías para reforzar SRP en este flujo de pagos? Comparte tus ideas y mejoras en los comentarios.

Alexander Flores Rayme

Hace 6 meses

import os

from dotenv import load_dotenv

import stripe

from dataclasses import dataclass

from stripe import StripeError

from stripe import PaymentIntent

from email.mime.text import MIMEText

from typing import Optional

load_dotenv()

STRIPE_SECRET_KEY = os.getenv('STRIPE_SECRET_KEY')

stripe.api_key = STRIPE_SECRET_KEY

## RESPONSABILITIES:

# 1. Data Models (Dataclasses): Estructura pura y validación básica.

# 2. Payment Service: Solo sabe hablar con Stripe.

# 3. Notification Service: Solo sabe enviar mensajes.

# 4. Logger Service: Solo sabe escribir en el archivo.

# 1. Data Models: se ecarga de representar los datos de cliente y pago, y realizar validaciones básicas.

@dataclass

class Customer:

name: str

contact_info: dict # Puede contener 'email' o 'phone'

def __post_init__(self):

if not self.name:

raise ValueError("Invalid Customer data: missing name")

if not self.contact_info:

raise ValueError("Invalid Customer data: missing contact info")

@dataclass

class PaymentRequest:

amount: int

source: str # Payment Method ID (pm_...)

cvv: int

currency: str = "usd"

def __post_init__(self):

if not self.source:

raise ValueError("Invalid payment data: missing source")

# 2. Payment Service: se encarga exclusivamente de interactuar con Stripe para procesar el pago.

class StripePaymentService:

def process_payment(self, customer: Customer, payment: PaymentRequest) -> PaymentIntent:

try:

payment_intent = stripe.PaymentIntent.create(

amount=payment.amount,

currency=payment.currency,

payment_method=payment.source,

confirm=True,

description=f"Pago de {customer.name}",

automatic_payment_methods={

'enabled': True,

"allow_redirects": 'never'

}

)

print("💰 Pago exitoso con PaymentIntent!")

print("🧾 ID del pago:", payment_intent.id)

print("📦 Estado:", payment_intent.status)

return payment_intent

except StripeError as e:

print(f'Payment failed: {e.user_message}')

raise e

# 3. Notification Service: se encarga exclusivamente de enviar notificaciones al cliente, ya sea por email o SMS.

class NotificationService:

def send_notification(self, customer: Customer, message: str):

email = customer.contact_info.get("email")

phone = customer.contact_info.get("phone")

if email:

self._send_email(email, message)

elif phone:

self._send_sms(phone, message)

else:

print("No valid contact information for notification")

def _send_email(self, email: str, message: str):

msg = MIMEText(message)

msg["Subject"] = "Payment Confirmation"

msg["From"] = "hola @begin.com"

msg["To"] = email

# server = smtplib.SMTP("localhost")

# server.send_message(msg)

# server.quit()

print("Email sent to", email)

def _send_sms(self, phone_number: str, message: str):

sms_gateway = "the custom SMS Gateway"

print(

f"send the sms using {sms_gateway}: SMS sent to {phone_number}: {message}"

)

# 4. Logger Service: se encarga exclusivamente de registrar las transacciones en un archivo de log.

class LoggerService:

def log_transaction(self, customer: Customer, payment: PaymentRequest, payment_intent: Optional[PaymentIntent]):

with open("transactions.log", "a") as log_file:

log_file.write(

f"{customer.name} paid {payment.amount}\n" # Registro de nombre y el monto pagado

)

if payment_intent:

log_file.write(f"Payment status: {payment_intent.status}\n") # Registro del estado del pago

else:

log_file.write("Payment status: failed\n") # Registro de fallo en el pago

class PaymentProcessor:

def __init__(self):

self.payment_service = StripePaymentService()

self.notification_service = NotificationService()

self.logger_service = LoggerService()

def process_transaction(self, costumer_data: dict, payment_data: dict):

try:

# Validación y creación de objetos de dominio

customer = Customer(**costumer_data) # name, contact_info

payment_request = PaymentRequest(**payment_data) # Amount, source, currency

# Procesamiento del pago

payment_intent = self.payment_service.process_payment(customer, payment_request)

# Envío de notificación al cliente

self.notification_service.send_notification(customer, "Thank you for your payment.")

self.logger_service.log_transaction(customer, payment_request, payment_intent)

print(f"✅ Proceso completado para {customer.name}")

except ValueError as e:

print(f"Data validation error: {e}")

except StripeError as e:

print(f"Payment processing error: {e.user_message}")

except Exception as e:

print(f"An unexpected error occurred: {e}")

if __name__ == '__main__':

processor = PaymentProcessor()

customer_data_with_email = {

"name": "John Doe",

"contact_info": {"email": "e@mail.com"},

}

customer_data_with_phone = {

"name": "Alexander Flores",

"contact_info": {"phone": "1234567890"},

}

payment_data = {"amount": 8000, "source": "pm_card_mastercard", "cvv": 123}

#processor.process_transaction(customer_data_with_email, payment_data)

processor.process_transaction(customer_data_with_phone, payment_data)

Comentarios (27)27 comentarios

Frank Casanova

Hace 2 años

Axel Díaz

Emilio Nicolás Mendoza Patti

Francisco Suriel Lino Cadena

Leonardo daniel Gutierrez Medellin

Samuel Steven Bernal Martínez

Hace un año

David Agudelo

César Ernesto Rivas Martínez

Mariano Gobea Alcoba

Ray Trápala

Gabriel de Jesus Chirinos Marcano

Jose Enrique Marquez

Camilo Taborda

José Alexander Márquez Rivera

cristian rojas

Adrián Millán

Frandy De La Cruz

Hace 2 meses

Federico Arias

Hace 7 meses

Eduardo José Álvarez

Team Platzi

Cesar Augusto Mora Castilo

Osnayder Severiche Urda

Gabriel Asborno

Hace 3 meses

Jhon Anderson Galeano Santillana

Hace 9 meses

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Qué es el principio de responsabilidad única

Procesador de pagos en Python con Stripe

Cómo aplicar SRP en un procesador de pagos con Stripe

Principio open-closed en Python

Clases abstractas y principio abierto-cerrado

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python

Principio de segregación de interfaces en SOLID

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias en SOLID

Principio de inversión de dependencias: servicio de pagos flexible

Reestructuración del proyecto

Reestructuración con módulos de Python y SOLID

Patrones de Diseño

Qué son los patrones de diseño: definición y categorías

Strategy Pattern con Python y setprocessor

Strategy Pattern para pagos en Python

Factory Pattern: centralizar creación de objetos

Patrón Factory para procesar pagos con match

Qué es el patrón Decorator

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder Pattern aplicado a un servicio de pagos

Observer Pattern en sistemas de eventos

Observer en sistemas de pagos con Python

Chain of Responsibility para validar pagos

Chain of Responsibility en servicios de pagos

Código funcional vs código mantenible en Python

Cómo aplicar SRP en un procesador de pagos con Stripe

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos