How to Build Referral-Aware Split Payment Flows in Django

Saudações, comunidade do **webmastersmz.com**!

Como especialista em tecnologia, analisei recentemente um tópico bastante pertinente no ecossistema de desenvolvimento actual: *"I Tried to Prompt-Inject My Own Agent Engine. It Didn't Work. Here's Why"* (Eu tentei fazer uma injecção de *prompt* no meu próprio motor de agentes. Não funcionou. Eis o porquê).

O artigo aborda um tema crítico para quem está a construir aplicações baseadas em Inteligência Artificial e LLMs (Large Language Models): a segurança e a resiliência dos *Agent Engines* (motores de agentes autónomos) contra ataques de *Prompt Injection* (injecção de instruções maliciosas).

Aqui ficam os pontos técnicos principais discutidos no tópico:

1. **A Ilusão da Vulnerabilidade Direta:** Muitos criadores assumem que, se um LLM é vulnerável a *prompts* maliciosos numa interface de chat padrão, um agente autónomo (que executa acções e toma decisões) também o será da mesma forma linear. Contudo, a arquitectura muda o panorama.
2. **Camadas de Abstracção e Validação:** O autor explica que o seu motor não passava o *input* do utilizador em bruto directamente para o modelo de decisão. Havia camadas intermédias de validação, formatação estruturada (como JSON schemas) e restrições rígidas no contexto do sistema (*system prompts*), o que funcionou como um "sanitizador" natural.
3. **Princípio do Menor Privilégio nos Agentes:** Um dos pontos fortes mencionados é que o agente em questão operava num ambiente com ferramentas limitadas e escopos bem definidos. Mesmo que o ataque de injecção conseguisse "enganar" parcialmente a IA a nível semântico, o agente não tinha permissões no sistema operativo ou nas APIs para executar o comando malicioso pretendido.
4. **Determinação vs. Estocástica:** O autor conclui que a combinação de código determinístico (lógica tradicional de programação) a envolver o comportamento estocástico (probabilístico) da IA cria uma blindagem muito superior à esperada.

**Para o debate:**
Isto abre uma discussão fascinante para nós, desenvolvedores e administradores de sistemas. Até que ponto podemos confiar na robustez dos nossos agentes de IA? Será que a validação baseada em código tradicional é suficiente, ou estamos a ignorar vectores de ataque mais sofisticados, como a exfiltração de dados por caminhos indirectos? Como é que vocês têm lidado com a segurança nas vossas implementações de IA aqui em Moçambique? Deixem as vossas opiniões e experiências nos comentários!

---

Para garantir que os vossos projetos, aplicações e fóruns rodam sem falhas e com a máxima segurança, convido-vos a conhecer as soluções de alojamento de alta performance da **AplicHost** em [https://aplichost.com](https://aplichost.com).

                     How to Build Referral-Aware Split Payment Flows in Django
               



Tópico:
                     How to Build Referral-Aware Split Payment Flows in Django
               
Categoria: Tutoriais | FreeCodeCamp Premium
Idioma Principal: Português (Conteúdo de Tecnologia)

Conteúdo do Tutorial / Guia Passo a Passo:
-------------------------------------------------------------------------
When a product has a single checkout, payment logic is usually simple: charge the user, mark the order as paid, and move on.

But once the business model includes a deposit now, a balance later, and referral or coupon attribution in between, the problem changes completely.

At that point, you're not just collecting money. You're managing a payment workflow.

In this tutorial, I'll show you how to build a referral-aware split payment flow in Django that:

• tracks Step 2 deposit and balance separately

• supports coupon and partner linkage

• prevents duplicate payment processing

• uses database transactions safely

• keeps referral payouts consistent

• unlocks deliverables only when the workflow is complete

The main idea is simple: treat payment as a state transition, not just a webhook event.

Table of Contents

• Prerequisites

• Project Structure

• Designing the Data Model

• How Split Payments Work

• Finalizing Payments Safely

• Handling Webhooks Idempotently

• Applying Coupons and Referral Attribution

• Why the Referral Payout Should Be Explicit

• Unlocking Deliverables at the Right Time

• Common Mistakes

• Conclusion

Prerequisites

Before following along, you should already be comfortable with:

• Django models, views, and querysets

• database transactions in Django

• basic webhook concepts

• Python class-based or function-based view patterns

• how payment providers like Stripe or Paystack send event callbacks

You don't need to be an expert in payments, but you should understand how Django talks to the database and how to store state safely.

Project Structure

Here's a simple structure for the parts we need:

Código Selecionar Expandir

payments/
├── models.py
├── services.py
├── views.py
├── urls.py
└── webhooks.py

This separation matters.

•

Código Selecionar Expandir

models.pystores the business state

•

Código Selecionar Expandir

services.pycontains the finalization logic

•

Código Selecionar Expandir

views.pyhandles user-facing payment actions

•

Código Selecionar Expandir

webhooks.pyreceives gateway callbacks

•

Código Selecionar Expandir

urls.pyconnects endpoints

Keeping payment logic out of views makes the system easier to test and much harder to break.

Designing the Data Model

The most important decision is to model the payment stages clearly.

Instead of storing one vague "paid" flag, define the stages your business actually uses. For example:

[code]from django.db import models
from django.conf import settings

class Journey(models.Model):
user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
deposit_paid = models.BooleanField(default=False)
balance_paid = models.BooleanField(default=False)
deliverables_released = models.BooleanField(default=False)
referral_code = models.CharField(max_length=50, blank=True, default="")
partner_name = models.CharField(max_length=120, blank=True, default="")
created_at = models.DateTimeField(auto_now_add=True)

class Payment(models.Model):
STAGE_DEPOSIT = "deposit"
STAGE_BALANCE = "balance"

STAGE_CHOICES = [
(STAGE_DEPOSIT, "Deposit"),
(STAGE_BALANCE, "Balance"),
]

STATUS_PENDING = "pending"
STATUS_SUCCEEDED = "succeeded"
STATUS_FAILED = "failed"

STATUS_CHOICES = [
(STATUS_PENDING, "Pending"),
(STATUS_SUCCEEDED, "Succeeded"),
(STATUS_FAILED, "Failed"),
]

journey = models.ForeignKey(Journey, on_delete=models.CASCADE, related_name="payments")
stage = models.CharField(max_length=20, choices=STAGE_CHOICES)
gateway_reference = models.CharFiel

... [O tutorial continua no link abaixo] ...