DEV Community: Payneteasy

The card number was in our error tracker, not our database

Payneteasy — Mon, 26 Oct 2026 00:00:17 +0000

We passed a PCI scoping review on the database side with no issues: no PANs stored, tokens only. Then someone searched our error tracker for a 6-digit BIN while debugging an unrelated decline and got hits.

The cause was boring. A JSON parse error in the checkout handler threw before validation, and the tracker's default integration attached the raw request body to the event. Anything a customer typed into the card field, when the payload was malformed, was stored in plaintext for 90 days. We found 41 events with full 16-digit numbers. All of them came from a mobile client version that sent a trailing comma.

What fixed it:

Scrub at the SDK before send, not in the tracker's UI. Server-side scrubbing still means the data crossed the wire to a third party.
Drop request bodies on payment routes entirely. Keep the route, status, and a request ID.
Add a Luhn-pattern check to the log pipeline as a tripwire. It catches the next leak, not the first one.
Same for reverse proxy access logs if you ever put card data in a query string. Don't.

The part that bothered me most: our scope diagram showed three boxes. The tracker wasn't one of them, because nobody thinks of it as a data store.

Where else have you found cardholder data you didn't expect: APM traces, support tool screenshots, analytics events?

Payneteasy handles this kind of payment flow for merchants and PSPs — see how it works.

Checkout.com Expands Into In-Person Payments: A Strategic Shift Toward Omnichannel

Payneteasy — Sun, 25 Oct 2026 00:00:16 +0000

Checkout.com, a leading global payment provider, has announced its entry into the in-person payments segment. The company says it is responding to significant demand from enterprise merchants who want the same performance and reliability in physical stores that they experience with online acquiring.

Why it matters. The payments market is moving toward convergence of online and offline channels. Merchants increasingly demand unified processing, unified reporting, and consistent fraud protection across all sales channels. Traditional PSPs that started with online acquiring now face the need to build or buy offline infrastructure. Checkout.com's expansion signals that even major online acquirers can no longer ignore the physical channel, especially in the enterprise segment.

Who is affected and how

PSPs and fintechs relying on white-label solutions. This move intensifies competition from global brands that can now offer merchants a full omnichannel cycle. Previously, differentiation through offline acquiring was possible; now that advantage is eroding. To stay competitive, these companies must focus on flexibility, local expertise, and customization for niche markets where global giants are less agile.
Enterprise merchants and marketplaces. For merchants using Checkout.com or similar platforms, this is a positive signal: growing competition in acquiring may lead to better terms and technologies. However, Checkout.com targets the large enterprise segment, while niche and customized solutions for PSPs and banks remain a distinct space where specialized providers can thrive.
Banks and financial institutions. Banks partnering with PSPs may see new opportunities to offer omnichannel capabilities to their corporate clients without building their own infrastructure. The entry of a global player like Checkout.com could also push banks to accelerate their own digital transformation in payments.

Bottom line

Checkout.com's expansion into in-person payments is a strategic move that transforms it from a purely online player into a universal omnichannel acquirer. For the industry, it underscores the necessity of unified payment solutions. For specialized providers, the key opportunity lies in offering more flexible integration, local market adaptation, and tailored services that global giants cannot easily replicate.

How will your payments strategy adapt to the growing demand for omnichannel solutions?

Source: Finextra, 20 Oct 2026

Payment engineers: which ops task would you hand to AI first?

Payneteasy — Sat, 24 Oct 2026 09:32:27 +0000

Logs, reports, routing rules, or bulk config changes across 50 gateways: which one eats your sprint?

We're polling payment teams on LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7519316013973188611

Drop your answer in the comments too. Tell us what tooling you use today and where it breaks.

On Monday, 26 Oct, we'll post how AI handles each case. Live demo at SiGMA Rome, 3–5 Nov, stand 3080:
https://cal.com/payneteasy/payneteasy-sigma-2026-meetings?utm_source=devto&utm_medium=social&utm_campaign=sigma_2026&utm_content=poll

Our webhook dedupe check was a race, not a guard

Payneteasy — Sat, 24 Oct 2026 00:00:15 +0000

We deduplicated webhooks the obvious way. Handler receives an event, runs SELECT on processed_events by event_id, and if nothing is found, does the work and inserts the row at the end.

It held for months. Then a customer got two receipt emails and a loyalty-points credit twice for the same payment.

The cause: the gateway redelivered the event 40 ms after the first attempt, because our first response was slow (a cold DB connection pushed it to about 3 seconds, and their timeout was 2). Both deliveries landed on different pods. Both ran the SELECT before either had inserted. Both saw an empty table, and both did the work.

In logs it looked like duplicate delivery, but the gateway was behaving correctly. Our check-then-act was the bug.

The fix was to flip the order. Insert the event_id first, into a table with a unique constraint, inside the same transaction as the side effects. If the insert hits a conflict, return 200 and stop. If the transaction fails, the insert rolls back and the next redelivery gets a clean retry.

Two details that mattered. We key on the event id, not the payment id, since one payment emits several events. And we return 200 on conflict, because a 4xx there makes the gateway keep retrying a event you've already handled.

How do you handle side effects that can't live in the same transaction, like email sends? Outbox table, or something else?

Payneteasy handles this kind of payment flow for merchants and PSPs — see how it works.

Our dunning job retried 'stolen card' declines every night

Payneteasy — Fri, 23 Oct 2026 00:00:16 +0000

Found this while looking at a scheme fee line that kept growing on a subscription product. The dunning job had one rule: if a renewal fails, retry at 24h, 72h and 7 days. It never looked at why the renewal failed.

The decline codes were the problem. Code 51 (insufficient funds) is a decent retry candidate, because the balance can change by payday. Codes 41 (lost card) and 43 (stolen card), and 14 (invalid card number), are different. The issuer is telling you not to come back, and no amount of waiting changes that. We were sending those through the same schedule anyway.

Visa and Mastercard both penalize this. As I understand Visa's rules, 'never approve' decline categories get no reattempts at all, and the other categories are capped at roughly 15 attempts in 30 days. Past that you pay per attempt, and the decline ratio on the merchant account climbs.

The fix was small. We map the response code to one of three buckets: retry later, retry only after the customer updates the card, and never retry. The 'never' bucket cancels the schedule and sends the customer to a payment-update page.

The lesson for me was that the gateway's raw response code belongs in your retry state, not just in the log line. If all you persist is 'failed', you can't build this.

How do you handle it? Do you keep your own decline-code table, or trust the normalized category your gateway returns?

Payneteasy handles this kind of payment flow for merchants and PSPs — see how it works.

Closing the Corporate Service Gap in Cross-Border Payments

Payneteasy — Thu, 22 Oct 2026 00:00:16 +0000

Corporate clients increasingly expect cross-border payments to feel as fast, transparent, and predictable as domestic ones. Yet traditional bank services often lag behind, creating what industry analysts call a 'service gap.' A recent Finextra analysis highlights how banks can adapt their products for international settlements to better meet corporate expectations.

Why it matters. For payment service providers (PSPs), merchants, banks, and fintechs, this shift directly impacts daily operations. When banks improve cross-border services, the entire payment chain benefits: faster settlements, fewer rejections, and a better experience for end customers. For partner banks, it's a chance to offer more competitive corporate products—especially as fintechs and neobanks aggressively capture market share.

Who is affected and how

PSPs and merchants. Improved bank services mean quicker fund flows and reduced friction in international transactions. This translates into lower operational overhead and higher satisfaction for merchants' own clients, who demand seamless global payments.
Banks and corporate clients. Banks that modernize their cross-border offerings can retain and attract corporate customers. The key levers include API-driven integration, transparent fee and timing structures, and flexible liquidity models—features that directly address the service gap.
Fintechs and neobanks. As banks close the gap, fintechs face both competition and opportunity. They can leverage white-label orchestration solutions to quickly align with evolving bank capabilities, without building infrastructure from scratch.

Bottom line

The trend is clear: corporate clients want seamlessness in international payments, and banks that fail to invest in modernization risk losing a profitable segment. For payment providers, this is a chance to position themselves as the technological bridge between traditional banks and modern business requirements. The faster banks adapt, the more partnership and integration opportunities emerge across the ecosystem.

How is your organization preparing for the shift toward more transparent and API-driven cross-border payments?

Source: Finextra, 12 Nov 2026

Your deploy can silently turn off your webhook endpoint

Payneteasy — Wed, 21 Oct 2026 00:00:15 +0000

We shipped a routine release on a Tuesday. Rolling restart, about 90 seconds where the webhook service returned 502 from the load balancer. Nobody noticed, because health checks were green again right after.

Two days later, support asked why a batch of orders was stuck in "pending" even though the customers had been charged.

The cause: the gateway retries failed deliveries on a schedule, and after enough consecutive failures it marks the endpoint as degraded and stops sending new events until someone re-enables it. Our 90-second window hit a burst of events, each one burned through its first retries, and the endpoint tripped. Everything after that point went nowhere. No alert fired on our side, because from our side there was simply no traffic.

What we changed:

Alert on the absence of webhooks, not only on errors. If zero events arrive for 15 minutes during business hours, page someone.
Keep a daily job that pulls recent transactions through the API and compares them with what the webhooks delivered. The webhook is a hint, the API is the source of truth.
Drain the webhook service last in the rollout, and never return 5xx while shutting down. Accept, queue, return 200.

Do you monitor for silence, or only for failures? I suspect most setups only cover the second one.

Payneteasy handles this kind of payment flow for merchants and PSPs — see how it works.

Our amount helper assumed every currency has two decimals

Payneteasy — Tue, 20 Oct 2026 00:00:15 +0000

Ran into this when a merchant added Japan and Kuwait to their storefront. Our amount helper did one thing: multiply by 100, round, send as an integer. Fine for USD and EUR, so nobody looked at it for two years.

JPY has zero decimal places in ISO 4217. A 1,000 yen basket went out as 100000, and the gateway read it as 100,000 yen. The 3DS challenge showed the customer the wrong number, which is the only reason we caught it in staging and not in a dispute queue.

KWD and BHD are the opposite: three decimals. A 12.500 KWD order sent as 1250 is 1.250 KWD. The charge succeeds, the customer is undercharged by 90%, and nothing errors. Nothing in the response tells you the exponent was wrong, because the amount is a valid integer either way.

The fix was boring: a lookup table of currency exponents, one function that converts to minor units, and a hard failure on unknown codes instead of a default of 2. We also added a test that round-trips every ISO 4217 code with a nonzero amount.

Two side effects: our reconciliation export had the same hard-coded divisor, and a couple of acquirers cap amounts per currency in minor units, so the cap check was wrong too.

Do you pull the exponent from a library, or maintain your own table? And how do you handle the currencies where the acquirer's exponent differs from ISO?

Vast Bank and Cliq: The Rise of Third-Party Payment Processors

Payneteasy — Mon, 19 Oct 2026 06:45:15 +0000

Vast Bank, a federally regulated national bank, has announced a multi-year partnership with fintech company Cliq. Under this agreement, Cliq will serve as a Third-Party Payment Processor (TPPP), providing the infrastructure to handle a wide range of transactions. The scope of services includes standard ACH payments, alternative payment methods, cryptocurrency and stablecoin solutions, and the issuance of business debit and prepaid cards.

This move highlights the enduring trend of Banking-as-a-Service (BaaS) and the delegation of operational functions to specialized fintech partners. For Vast Bank, this allows for product scaling without the need to invest in complex proprietary payment infrastructure, particularly in the fast-growing crypto payment segment. For Cliq, it serves as validation of its maturity as an infrastructure player capable of serving regulated financial institutions.

Why it matters.
This partnership underscores a significant shift in the payments landscape where the boundary between banks and fintechs is blurring. The key asset is no longer just the banking license, but the quality of the payment infrastructure and the speed of adopting new payment methods. It signals that regulators are increasingly accepting crypto and stablecoin models when they are integrated into the legal banking framework through reliable partners.

Who is affected and how

PSPs and Banks: The TPPP model is gaining traction as banks seek flexible partners offering "all-in-one" solutions, from ACH to crypto. This creates competition for traditional processors but opens niches for specialized solutions. PSPs working with banks must anticipate that their clients will actively seek external partners to expand functionality.
Merchants and Marketplaces: New TPPP partnerships may expand payment method choices for end-users. If Vast Bank offers corporate clients access to crypto payments via Cliq, it could impact the B2B payment ecosystem. Marketplaces and large merchants are increasingly considering stablecoins as a tool for cross-border settlements, potentially lowering friction and costs.
Regulatory Context: Partnering with a federally regulated bank emphasizes that crypto and stablecoin solutions are gradually being integrated into the legal banking perimeter. For fintechs, this is a signal that such models are permissible when backed by a solid banking partner, reducing regulatory uncertainty for infrastructure providers.

Bottom line

The Vast Bank and Cliq deal confirms that infrastructure quality and speed of innovation are now more critical than traditional banking barriers. As banks outsource complex processing to specialized fintechs, the market is moving toward a more modular and competitive payment ecosystem.

How do you see the role of TPPPs evolving in the next five years?

Source: Finextra, 15 Oct 2026

A client timeout is not a decline

Payneteasy — Fri, 16 Oct 2026 08:00:15 +0000

Our HTTP client timeout for the charge call was 10 seconds. The gateway's upstream timeout to the issuer was 30. Most auths come back in 1-2 seconds, so nobody noticed the gap.

Then one issuer's processor started taking 12-15 seconds on a bad afternoon. Our client gave up at 10, logged "payment failed", and showed the customer a retry button. The auth was still in flight and succeeded at second 13. The customer clicked retry, the new attempt got a fresh order ID, and we ended up with two approved authorizations on one cart. A cleanup job voided one of them hours later, but the cardholder's available balance stayed held twice for days.

The mistake was treating a timeout as a decline. A timeout is a third state: unknown. The fix was small:

On timeout, mark the payment pending_unknown, not failed
Poll the gateway by our merchant order ID for up to 60 seconds before allowing a new attempt
Reuse the same order ID and idempotency key on retry, so the gateway returns the original result
Set the client timeout above the gateway's upstream timeout, not below it

Duplicate holds on slow-issuer days dropped to zero over the next two weeks.

How do you handle the unknown state in your checkout? Do you block the retry button, or let the idempotency key sort it out?

Webhook signature fails only when the payload has a slash in it

Payneteasy — Thu, 15 Oct 2026 07:30:17 +0000

Webhook signature check passed in staging for weeks, then started rejecting about 4% of production events. No pattern in event type, amount, or time of day.

The handler used express.json() to parse the body, then verified the HMAC against JSON.stringify(req.body). Parse, re-serialize, compare. It looks harmless, and it matches the signature whenever the sender's serializer and ours produce identical bytes.

They don't always. The gateway's backend escapes forward slashes ("https:\/\/shop.example\/return") and non-ASCII characters ("Jos\u00e9"). JSON.stringify does neither. So any event carrying a return URL, a cardholder name with an accent, or a descriptor with a slash got a different byte sequence and a different HMAC. Our staging fixtures were all ASCII names and had no URLs, so every test event passed.

The bad fix is to normalize the output until it matches. It will break again the next time someone adds a field or the sender changes a library version.

The actual fix: the signature is over the bytes that were sent, so verify the bytes that were received. Capture the raw body before any parser touches it (express.raw() or the verify callback on express.json()), compute HMAC-SHA256 over that buffer, compare with timingSafeEqual, and only then JSON.parse.

We also added one fixture with a slash, an accented name, and an emoji in the descriptor. It fails loudly if anyone puts a parser back in front of the check.

Has anyone hit a variant of this with a gateway that signs a canonicalized body instead of the raw one?

Our synchronous response said success. The webhook disagreed four seconds later.

Payneteasy — Sat, 10 Oct 2026 00:00:15 +0000

Checkout flow: call charge endpoint, get back status: approved synchronously, show the confirmation page, write the order to the DB as paid. Standard stuff.

Then the webhook for the same transaction lands 2-6 seconds later. Most of the time it just confirms what we already knew. Except for a window where the issuer sends a late decline after the gateway already told us approved — card network risk check flagged it post-authorization, something like 1 in 3000 transactions on one acquirer.

Our order write happened on the sync response. The webhook handler had no idea an order even existed yet when it tried to update status, because the DB write from the sync path hadn't committed. Webhook processed against a row that didn't exist, silently no-op'd, and we shipped a product against a transaction that got reversed six hours later in the settlement file.

Fix was boring: webhook handler now upserts instead of updates, and order state transitions go through a queue instead of direct writes so ordering is enforced regardless of which path (sync response or webhook) arrives first.

Curious how other people handle the case where your own synchronous API response can't be trusted as final. Do you delay fulfillment until the webhook confirms, even on providers where that adds real latency to checkout?