DEV Community: cendyandreoli

Quanto custa vender a prazo para o varejo? Uma conta aberta

cendyandreoli — Mon, 09 Nov 2026 20:43:58 +0000

Quem vende a prazo para o varejo costuma olhar só para o atraso. Mas o prazo em si já custa, mesmo quando o lojista paga em dia. Segue uma conta com números de demonstração (não é resultado de cliente).

Cenário: venda de R$ 100.000, prazo de 60 dias, custo do dinheiro de 2% ao mês, 10% das vendas pagas com atraso médio de 15 dias, perda definitiva de 1%.

Parte	Conta	Valor
Prazo	R$ 100.000 x (1,02² − 1)	R$ 4.040
Atraso	R$ 100.000 x 10% x (1,02^0,5 − 1)	R$ 99,50
Perda	R$ 100.000 x 1%	R$ 1.000
Total	soma	R$ 5.139,50 (5,14% da venda)

O que se aprende com a conta

O maior pedaço é o prazo, não a inadimplência. Reduzir calote não zera o custo de vender a prazo.
Uma garantia atua sobre a linha da perda. O custo do prazo continua. A pergunta útil é se o custo da garantia fica abaixo da perda que ela evita.
Como régua de mercado, o Banco Central publica a inadimplência da carteira de crédito de pessoas jurídicas: 4,98% em setembro de 2026 (série SGS 21082). Ela mede crédito bancário a empresas, não venda a prazo entre indústria e varejo; serve só de referência.

Uma forma de garantia que existe hoje

Recebíveis de cartão do lojista, já registrados em registradora, podem servir de lastro para a venda feita a ele. O registro é regulado pelo Banco Central (Resolução BCB nº 264, de 25/11/2022). Não é antecipação: o recebível continua sendo do lojista, que é o comprador.

Quer refazer a conta com os seus números? A calculadora é aberta.
Explicação completa, com comparação entre garantia, duplicata, seguro e factoring: garantia para venda a prazo.

Texto da equipe do ArcusPay. O ArcusPay não é banco e trabalha com parceiros regulados pelo Banco Central.

Issue Brazilian invoices from Claude with an MCP server (and a human approval step)

cendyandreoli — Mon, 09 Nov 2026 20:19:34 +0000

Brazilian service invoices (NFS-e) are issued per city or through a national system, and every field is checked by tax authorities. SendNF exposes this as an API and as an MCP server, so an AI agent can look up a company by CNPJ, preview an invoice and issue it.

What you need

An API key. Keys that start with nt_test_ are sandbox keys (no tax value). nt_live_ keys issue real invoices.
An MCP client such as Claude or Cursor.

Configure

{
  "mcpServers": {
    "sendnf": {
      "type": "http",
      "url": "https://api.sendnf.com/mcp",
      "headers": { "Authorization": "Bearer nt_test_YOUR_KEY" }
    }
  }
}

The server uses Streamable HTTP, with no session. Without a key it answers 401.

What the agent can do (44 tools)

Read: lookup_cnpj (public data from the tax authority, and which city system applies), search_service_codes (national service list, LC 116, with NBS), check_readiness (what is still missing for a company), validate_dps (checks a DPS XML against the official layout; it does not guarantee acceptance by the city).
Preview without sending: preview_nfse, preview_nfce, preview_nfe.
Issue: issue_nfse, issue_nfce, issue_nfe, and cancel_document.

The human approval step
By default, any key used through MCP requires approval. create_note_draft builds the invoice, validates it and leaves it as pending_approval (NFS-e drafts come with a PDF preview). Nothing goes to the tax authority until a person approves in the dashboard or through the approver link. Approval expires in 7 days, and the audit log records who approved, when and from which IP.

Limits
The repository https://github.com/sendnf/sendnf-mcp has the manifest, examples and tool list; the product code is private. SendNF issues NFS-e (MEI, Simples Nacional, Lucro Presumido and Lucro Real), NFC-e and NF-e (model 55; MEI and Simples Nacional); it does not issue CT-e or MDF-e. Docs: https://sendnf.com/mcp/ . Plans and prices: https://sendnf.com/precos/ .

Reading Brazil's credit card revolving rate from the central bank API (no key needed)

cendyandreoli — Mon, 09 Nov 2026 20:17:57 +0000

Brazil's central bank (Banco Central do Brasil) publishes the average revolving credit card rate for individuals as series 25477 in its SGS time-series service. The API is public, needs no key and returns JSON.

curl -s "https://api.bcb.gov.br/dados/serie/bcdata.sgs.25477/dados?formato=json&dataInicial=01/09/2025&dataFinal=30/09/2026"

Each row looks like {"data":"01/09/2026","valor":"15.29"}. The value is the monthly rate in percent, as a string, and the date is always day 01 of the month.

What I got

September 2026: 15.29% per month.
September 2025: 15.23% per month.
The monthly rate stayed between 14.90% (Jan 2026) and 15.44% (May 2025) over the last 24 months.

Turning monthly into yearly

The API gives monthly only. The yearly rate is (1 + m)^12 - 1:

m = 0.1529
print(round(((1 + m) ** 12 - 1) * 100, 2))  # 451.44

R$ 1,000 left untouched for 12 months at that rate becomes about R$ 5,514 (1000 * 1.1529 ** 12). In Brazil, Law 14.690/2023 caps interest and fees at 100% of the original debt, so the real ceiling is double.

Gotchas

valor is a string with a dot, not a comma.
Date params use dd/mm/aaaa, not ISO.
The series is the average reported by institutions, not the rate on your card.

I put the full 24-month table and the method on a page (in Portuguese), with sentences ready to cite: https://tobbofin.com/calculadoras/juros-do-cartao-banco-central/. I work on Tobbo, a personal finance app for Android that connects to Brazilian banks through Open Finance. The page is ours.

Source: Banco Central do Brasil, SGS series 25477, checked on 2026-11-09.

VERP and Automated Bounce Handling: DSN Parsing Explained

cendyandreoli — Mon, 09 Nov 2026 13:08:07 +0000

VERP (Variable Envelope Return Path) is a bounce-handling technique in which every message is sent with a unique envelope sender, such as bounce-7f3k9q@bounces.example.com, that encodes which recipient or message it belongs to. When a delivery failure comes back, the address it was sent to tells you exactly which recipient failed, even if the bounce body is malformed. A complete automated pipeline combines VERP for identification, RFC 3464 Delivery Status Notification (DSN) parsing for the reason, and filters that separate real bounces from auto-replies and other noise.

Why bounce handling is harder than it looks

Synchronous failures are easy: your MTA receives 550 5.1.1 User unknown during the SMTP session and records it. The hard part is asynchronous bounces. A server accepts the message, then later finds it cannot deliver it and sends a new message back to the envelope sender.

Those messages are inconsistent. Many follow RFC 3464, but some servers send free-text bounces, some rewrite the recipient after forwarding, and some report an internal alias rather than the address you sent to. If you rely on parsing the human-readable text to find the recipient, you will mismatch or miss bounces. VERP removes that guesswork.

How VERP works

Without VERP, all mail uses one return-path:

MAIL FROM:<bounces@example.com>

With VERP, the local part becomes unique per recipient or per message:

MAIL FROM:<b-01HZX4Q7M2-jane=example.net@bounces.example.com>

The classic VERP format, as introduced for qmail, embeds the recipient address with @ replaced by =. Modern systems usually prefer an opaque token instead, which does not leak the recipient address and keeps the local part short:

MAIL FROM:<b-7f3k9q2xv1@bounces.example.com>

The token maps (in a database or through an HMAC-signed encoding) to the message ID, the recipient and the stream. When a bounce arrives at b-7f3k9q2xv1@bounces.example.com, you look up the token and know exactly what failed.

DNS for the bounce domain

The return-path domain must receive mail and authorize your sending IPs:

bounces.example.com.  IN MX   10 inbound.example.com.
bounces.example.com.  IN TXT  "v=spf1 ip4:203.0.113.0/28 -all"

Because it is a subdomain of example.com, SPF aligns with a From: ...@example.com address under DMARC relaxed alignment (RFC 7489). VERP and DMARC work together without conflict.

Token design tips

Keep the local part under 64 octets (the RFC 5321 limit).
Use only lowercase letters and digits; some systems lowercase or mangle case and punctuation.
Sign tokens or make them unguessable, so attackers cannot forge bounces that unsubscribe your users.
Keep the mapping for as long as bounces can arrive (days, not minutes).

Anatomy of a DSN

A standards-compliant bounce is a multipart/report message (RFC 6522) with report-type=delivery-status. It is sent with an empty envelope sender (MAIL FROM:<>) so that bounces never generate more bounces.

Return-Path: <>
To: b-7f3k9q2xv1@bounces.example.com
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status; boundary="XYZ"

--XYZ
Content-Type: text/plain

The following address failed: jane@example.net

--XYZ
Content-Type: message/delivery-status

Reporting-MTA: dns; mx1.example.net
Arrival-Date: Mon, 12 Oct 2026 14:03:20 +0000

Final-Recipient: rfc822; jane@example.net
Original-Recipient: rfc822; jane@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mailstore3.example.net
Diagnostic-Code: smtp; 550 5.1.1 <jane@example.net>: Recipient address rejected: User unknown

--XYZ
Content-Type: message/rfc822-headers

Message-ID: <01HZX4Q7M2@mail.example.com>
From: Example <hello@example.com>
--XYZ--

The fields defined by RFC 3464 that matter:

Action: failed, delayed, delivered, relayed or expanded. Only failed is a bounce. delayed is a warning that the remote server is still retrying.
Status: the enhanced status code (RFC 3463), for example 5.1.1 or 4.2.2.
Diagnostic-Code: the remote server's actual reply, useful for classification and debugging.
Final-Recipient and Original-Recipient: which address failed. With VERP you use these to cross-check, not as the source of truth.

The third part, either message/rfc822 or message/rfc822-headers, contains the original message or its headers. Your own Message-ID there is a second way to correlate.

Bounces vs auto-replies vs everything else

The return-path address receives more than bounces. Classify every inbound message before acting:

Message	How to recognize it	Action
DSN failure	`multipart/report; report-type=delivery-status`, `Action: failed`	Classify by Status, maybe suppress
DSN delay	Same, `Action: delayed`	Record, do not suppress
Auto-reply	`Auto-Submitted: auto-replied` (RFC 3834), `X-Autoreply`, Precedence `auto_reply`, normal content type	Ignore for suppression
Challenge-response	Asks you to verify you are human	Ignore
Non-standard bounce	Plain text with phrases like "user unknown", from `MAILER-DAEMON` or `postmaster`	Heuristic parsing, conservative actions
Complaint (ARF)	`multipart/report; report-type=feedback-report` (RFC 5965)	Route to complaint handling
Human reply	Anything else	Forward to a mailbox or drop by policy

Never suppress an address because of an out-of-office reply. The mailbox exists, and the person will be back.

A processing pipeline

inbound SMTP (bounces.example.com)
  -> accept; store raw message
  -> resolve VERP token -> (message_id, recipient, stream)
  -> classify: dsn | arf | auto-reply | unknown
  -> dsn: parse per-recipient fields; for each Action=failed
         -> classify Status: address | transient | policy
         -> address: add to suppression list (global)
         -> transient: count toward soft-bounce threshold
         -> policy: record + alert, no suppression
  -> emit event (bounced / delayed / complained) to webhooks

Implementation notes:

Store the raw message before parsing, so you can reprocess when you improve the parser.
Make processing idempotent: the same bounce can arrive twice, and retries happen.
Handle multiple recipients in one DSN; each recipient has its own section.
Fall back gracefully when the DSN is not standard: if the VERP token resolves but the body cannot be parsed, record an "unknown failure" rather than guessing a hard bounce.
Reject unknown tokens with a 550 or accept and discard. Do not let your bounce domain become an open relay or backscatter target.

Common mistakes

One static return-path and regex parsing of bounce bodies to find the recipient.
Treating Action: delayed as a bounce.
Suppressing on auto-replies or challenge-response messages.
Return-path on a domain that does not align with the From domain, which breaks SPF alignment for DMARC.
Forgeable tokens that let anyone suppress arbitrary recipients.
Short token retention, so late bounces cannot be matched.

Checklist

[ ] Unique, signed VERP token per message or recipient
[ ] Bounce subdomain with MX and SPF, aligned with From
[ ] RFC 3464 parser handling multiple recipients and all Action values
[ ] Separate paths for DSNs, ARF reports and auto-replies
[ ] Raw message storage and idempotent processing
[ ] Address, transient and policy failures handled differently

Pidgely uses VERP on a custom return-path subdomain for every message, parses DSNs and ARF reports on its own inbound servers, and turns them into bounce and complaint events with automatic suppression.

Originally published at pidgely.com. Pidgely is a transactional and marketing email API with built-in bounce handling: pidgely.com.