0Pricing
Vibe Coding · 강의

안전하게 결제 검증하기

클라이언트가 아니라 서버를 신뢰하세요.

안전하게 결제 검증하기은(는) CoddyKit의 무료 Vibe Coding 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Vibe Coding 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Vibe Coding 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Trust Nothing From the Client

The golden rule of payment security: the client can lie. A success page, a query parameter, a JavaScript callback — all can be forged or replayed by a determined user.

Access and fulfilment must be decided by signals you can cryptographically trust, originating from the provider's servers, never from the user's browser.

Webhook Signature Verification

Webhooks arrive at a public URL, so anyone could POST fake events to it. Providers sign each webhook with a secret only you and they know.

Always verify the signature before trusting the payload. An unsigned or mis-signed request must be rejected outright — this single check blocks the most common payment exploit.

Write a webhook endpoint that verifies the Stripe-Signature header using my webhook signing secret before processing the event. If verification fails, return 400 and do nothing. Explain exactly what attack this prevents.

Verify the Amount and Currency

Even a genuine, signed event must be checked against your expectations. Confirm the amount and currency match what the order should have cost.

If a $9 order reports a $0.50 payment, reject it. Signature proves the message is from the provider; amount-checking proves the customer paid what they owe.

In my checkout.session.completed handler, after verifying the signature, look up the expected price for the order from my database and confirm the paid amount and currency match before granting access. Show the rejection path if they differ.

Idempotent Webhook Handling

Providers deliver webhooks at least once, meaning duplicates are normal. If your handler grants credits or extends a subscription, processing the same event twice causes real harm.

Record each event ID you have processed and skip repeats. Make your handler safe to run any number of times for the same event.

Make my webhook handler idempotent: store each processed event ID in a table, and at the start of the handler skip any event ID already seen. Show the race-safe insert so two simultaneous deliveries can't both process the event.

Reconcile, Don't Assume

Verification means matching the provider's record to your own. Pull the authoritative object — the payment intent or subscription — and compare its status to what you expect before acting.

Re-fetching from the provider's API inside the handler closes the gap between a possibly stale event and current reality.

After receiving a payment webhook, re-fetch the PaymentIntent from Stripe by ID and confirm its status is 'succeeded' before fulfilling, rather than trusting the event payload alone. Explain when the live object and the event can disagree.

Respond Fast, Process Safely

Providers expect a quick 2xx response or they retry, causing duplicate deliveries. Acknowledge receipt promptly, then do heavy work asynchronously.

The pattern: verify the signature, enqueue the event, return 200. A background worker performs fulfilment. This keeps the endpoint reliable under load and during slow operations.

Refactor my webhook so it verifies the signature, pushes the event onto a job queue, and immediately returns 200. A separate worker does fulfilment. Explain why slow inline processing causes Stripe to retry and create duplicates.

Keep Secrets Out of Code

API keys, webhook secrets, and signing keys are credentials. Hard-coding them in source or shipping them to the client is a breach waiting to happen.

Store them in environment variables or a secrets manager. The secret key must live only on your server; the client gets the publishable key, which is safe to expose.

Audit my payment integration for leaked secrets: confirm the secret key and webhook signing secret are read from environment variables and never bundled into client code. Show the correct split between publishable and secret keys.

Handling Refunds and Disputes

Money flows backward too. A refund or a chargeback dispute should revoke access or adjust entitlements, driven by webhook events like charge.refunded and charge.dispute.created.

If you only handle the payment and ignore the reversal, a refunded customer keeps paid features for free. Wire the backward events as carefully as the forward ones.

Handle charge.refunded and charge.dispute.created webhooks: when a payment is reversed, revoke the matching entitlement and log it. Show how to find which user and order the refund corresponds to so I revoke the right access.

Logging and Auditing

When money is involved, you need an immutable trail. Log every webhook received, every fulfilment decision, and every entitlement change with timestamps and IDs.

This audit log is your defense in a dispute and your fastest debugging tool when a customer says "I paid but have no access". Never log raw card data, only references.

Failing Safely

When verification fails — bad signature, mismatched amount, unknown order — the safe default is to deny access and alert yourself, not to grant the benefit of the doubt.

A payment system should fail closed. A false negative annoys one customer you can fix manually; a false positive gives away your product or invites fraud.

Review my webhook handler's failure paths and make it fail closed: any verification or lookup failure denies access, logs the incident, and alerts me, rather than defaulting to granting access. List every branch that could accidentally grant access on error.

A Verification Checklist

Before going live, confirm the chain: signature verified, amount and currency matched, event idempotently processed, provider object reconciled, secrets in env, refunds handled, and failures fail closed.

Ask your AI assistant to audit the integration against this list. Each item that is missing is a door an attacker or a bug can walk through.

Audit my entire payment integration against this checklist and report any gaps: webhook signature verified, amount and currency validated, idempotent event handling, provider-side reconciliation, secrets in environment variables, refund and dispute handling, and fail-closed on errors.

Quick Check

Confirm the first thing every webhook handler must do.

Recap

Safe verification means trusting only the provider's signed server-side signals. Verify every webhook's signature, then check the amount and currency, process events idempotently, and reconcile against the live provider object before granting access.

Keep secrets in environment variables, respond fast and process asynchronously, handle refunds and disputes by revoking access, log an audit trail, and always fail closed. Run the full checklist before going live.

자주 묻는 질문

“안전하게 결제 검증하기” 강의는 무료인가요?

네 — “안전하게 결제 검증하기” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Vibe Coding 강의 전체를 잠금 해제할 수 있습니다. Vibe Coding 강의에는 총 4개의 강의가 포함되어 있습니다.

“안전하게 결제 검증하기”에서 뭘 배우나요?

클라이언트가 아니라 서버를 신뢰하세요. 브라우저에서 직접 실행하는 실습 코드로 Vibe Coding을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Vibe Coding을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Vibe Coding은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“안전하게 결제 검증하기” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Vibe Coding 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Vibe Coding 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. 결제 개념
  2. 결제 화면 설정하기
  3. 구독 관리하기
  4. 안전하게 결제 검증하기
← Vibe Coding(으)로 돌아가기