Trifecta Approach: Forward Email이 Stripe와 PayPal을 사용하여 방탄 결제 시스템을 구축한 방법
당사 개발팀이 전체 시스템에서 1:1 실시간 정확성을 보장하는 3중 접근법을 사용하여 Stripe와 PayPal을 어떻게 통합했는지 알아보세요.
머리말
Forward Email에서 우리는 항상 신뢰할 수 있고 정확하며 사용자 친화적인 시스템을 만드는 것을 우선시했습니다. 결제 처리 시스템을 구현할 때, 우리는 완벽한 데이터 일관성을 유지하면서 여러 결제 프로세서를 처리할 수 있는 솔루션이 필요하다는 것을 알았습니다. 이 블로그 게시물에서는 개발팀이 전체 시스템에서 1:1 실시간 정확성을 보장하는 트리펙타 방식을 사용하여 Stripe와 PayPal을 모두 통합한 방법을 자세히 설명합니다.
과제: 여러 결제 처리업체, 진실의 단일 소스
개인정보 보호 중심 이메일 서비스로서, 우리는 사용자에게 결제 옵션을 제공하고 싶었습니다. 어떤 사람들은 Stripe를 통한 신용카드 결제의 간편함을 선호하는 반면, 다른 사람들은 PayPal이 제공하는 추가적인 분리 계층을 중시합니다. 그러나 여러 결제 프로세서를 지원하면 상당한 복잡성이 발생합니다.
- 다양한 결제 시스템에서 일관된 데이터를 보장하려면 어떻게 해야 하나요?
- 분쟁, 환불, 결제 실패 등 예외적인 경우는 어떻게 처리하나요?
- 우리는 어떻게 데이터베이스에서 단일 진실의 원천을 유지할 수 있을까?
우리의 솔루션은 "트리펙타 접근 방식"이라고 부르는 것을 구현하는 것이었습니다. 이는 무슨 일이 있어도 중복성을 제공하고 데이터 일관성을 보장하는 3중 계층 시스템입니다.
Trifecta 접근 방식: 신뢰성의 세 가지 계층
당사의 결제 시스템은 완벽한 데이터 동기화를 보장하기 위해 함께 작동하는 세 가지 중요한 구성 요소로 구성되어 있습니다.
- 결제 후 리디렉션 - 결제 후 즉시 결제 정보 수집
- 웹훅 핸들러 - 결제 프로세서에서 실시간 이벤트 처리
- 자동화된 작업 - 결제 데이터를 주기적으로 검증하고 조정합니다.
각 구성 요소를 자세히 살펴보고 그것들이 어떻게 함께 작동하는지 살펴보겠습니다.
flowchart TD
User([User]) --> |Selects plan| Checkout[Checkout Page]
%% Layer 1: Post-checkout redirects
subgraph "Layer 1: Post-checkout Redirects"
Checkout --> |Credit Card| Stripe[Stripe Checkout]
Checkout --> |PayPal| PayPal[PayPal Payment]
Stripe --> |Success URL with session_id| SuccessPage[Success Page]
PayPal --> |Return URL| SuccessPage
SuccessPage --> |Verify payment| Database[(Database Update)]
end
%% Layer 2: Webhooks
subgraph "Layer 2: Webhook Handlers"
StripeEvents[Stripe Events] --> |Real-time notifications| StripeWebhook[Stripe Webhook Handler]
PayPalEvents[PayPal Events] --> |Real-time notifications| PayPalWebhook[PayPal Webhook Handler]
StripeWebhook --> |Verify signature| ProcessStripeEvent[Process Stripe Event]
PayPalWebhook --> |Verify signature| ProcessPayPalEvent[Process PayPal Event]
ProcessStripeEvent --> Database
ProcessPayPalEvent --> Database
end
%% Layer 3: Automated jobs
subgraph "Layer 3: Bree Automated Jobs"
BreeScheduler[Bree Scheduler] --> StripeSync[Stripe Sync Job]
BreeScheduler --> PayPalSync[PayPal Sync Job]
BreeScheduler --> AccuracyCheck[Subscription Accuracy Check]
StripeSync --> |Verify & reconcile| Database
PayPalSync --> |Verify & reconcile| Database
AccuracyCheck --> |Ensure consistency| Database
end
%% Edge cases
subgraph "Edge Case Handling"
ProcessStripeEvent --> |Fraud detection| FraudCheck[Fraud Check]
ProcessPayPalEvent --> |Dispute created| DisputeHandler[Dispute Handler]
FraudCheck --> |Ban user if fraudulent| Database
DisputeHandler --> |Accept claim & refund| Database
FraudCheck --> |Send alert| AdminNotification[Admin Notification]
DisputeHandler --> |Send alert| AdminNotification
end
%% Style definitions
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
classDef tertiary fill:green,stroke:#333,stroke-width:1px;
class Checkout,SuccessPage primary;
class Stripe,PayPal,StripeWebhook,PayPalWebhook,BreeScheduler secondary;
class FraudCheck,DisputeHandler tertiary;
1계층: 체크아웃 후 리디렉션
우리의 트리펙타 접근 방식의 첫 번째 계층은 사용자가 결제를 완료한 직후에 발생합니다. Stripe와 PayPal은 모두 사용자를 거래 정보와 함께 우리 사이트로 다시 리디렉션하는 메커니즘을 제공합니다.
Stripe 체크아웃 구현
Stripe의 경우, Checkout Sessions API를 사용하여 원활한 결제 경험을 만듭니다. 사용자가 플랜을 선택하고 신용 카드로 결제하기로 선택하면 특정 성공 및 취소 URL이 있는 Checkout Session을 만듭니다.
const options = {
mode: paymentType === 'one-time' ? 'payment' : 'subscription',
customer: ctx.state.user[config.userFields.stripeCustomerID],
client_reference_id: reference,
metadata: {
plan
},
line_items: [
{
price,
quantity: 1,
description
}
],
locale: config.STRIPE_LOCALES.has(ctx.locale) ? ctx.locale : 'auto',
cancel_url: `${config.urls.web}${ctx.path}${
isMakePayment || isEnableAutoRenew ? '' : `/?plan=${plan}`
}`,
success_url: `${config.urls.web}${ctx.path}/?${
isMakePayment || isEnableAutoRenew ? '' : `plan=${plan}&`
}session_id={CHECKOUT_SESSION_ID}`,
allow_promotion_codes: true
};
// Create the checkout session and redirect
const session = await stripe.checkout.sessions.create(options);
const redirectTo = session.url;
if (ctx.accepts('html')) {
ctx.status = 303;
ctx.redirect(redirectTo);
} else {
ctx.body = { redirectTo };
}
여기서 중요한 부분은 다음과 같습니다. success_url 매개변수에는 다음이 포함됩니다. session_id 쿼리 매개변수로. Stripe가 성공적인 결제 후 사용자를 다시 사이트로 리디렉션하면 이 세션 ID를 사용하여 거래를 확인하고 그에 따라 데이터베이스를 업데이트할 수 있습니다.
PayPal 결제 흐름
PayPal의 경우, 우리는 그들의 주문 API에 비슷한 접근 방식을 사용합니다:
const requestBody = {
intent: 'CAPTURE',
application_context: {
cancel_url: `${config.urls.web}${ctx.path}${
isMakePayment || isEnableAutoRenew ? '' : `/?plan=${plan}`
}`,
return_url: `${config.urls.web}${ctx.path}/?plan=${plan}`,
brand_name: 'Forward Email',
shipping_preference: 'NO_SHIPPING',
user_action: 'PAY_NOW'
},
payer: {
email_address: ctx.state.user.email
},
purchase_units: [
{
reference_id: ctx.state.user.id,
description,
custom_id: sku,
invoice_id: reference,
soft_descriptor: sku,
amount: {
currency_code: 'USD',
value: price,
breakdown: {
item_total: {
currency_code: 'USD',
value: price
}
}
},
items: [
{
name,
description,
sku,
unit_amount: {
currency_code: 'USD',
value: price
},
quantity: '1',
category: 'DIGITAL_GOODS'
}
]
}
]
};
Stripe와 유사하게 우리는 다음을 지정합니다. return_url 그리고 cancel_url 결제 후 리디렉션을 처리하기 위한 매개변수. PayPal이 사용자를 다시 당사 사이트로 리디렉션하면, 당사는 결제 세부 정보를 캡처하고 당사 데이터베이스를 업데이트할 수 있습니다.
sequenceDiagram
participant User
participant FE as Forward Email
participant Stripe
participant PayPal
participant DB as Database
participant Bree as Bree Job Scheduler
%% Initial checkout flow
User->>FE: Select plan & payment method
alt Credit Card Payment
FE->>Stripe: Create Checkout Session
Stripe-->>FE: Return session URL
FE->>User: Redirect to Stripe Checkout
User->>Stripe: Complete payment
Stripe->>User: Redirect to success URL with session_id
User->>FE: Return to success page
FE->>Stripe: Verify session using session_id
Stripe-->>FE: Return session details
FE->>DB: Update user plan & payment status
else PayPal Payment
FE->>PayPal: Create Order
PayPal-->>FE: Return approval URL
FE->>User: Redirect to PayPal
User->>PayPal: Approve payment
PayPal->>User: Redirect to return URL
User->>FE: Return to success page
FE->>PayPal: Capture payment
PayPal-->>FE: Return payment details
FE->>DB: Update user plan & payment status
end
%% Webhook flow (asynchronous)
Note over Stripe,PayPal: Payment events occur (async)
alt Stripe Webhook
Stripe->>FE: Send event notification
FE->>FE: Verify webhook signature
FE->>DB: Process event & update data
FE-->>Stripe: Acknowledge receipt (200 OK)
else PayPal Webhook
PayPal->>FE: Send event notification
FE->>FE: Verify webhook signature
FE->>DB: Process event & update data
FE-->>PayPal: Acknowledge receipt (200 OK)
end
%% Bree automated jobs
Note over Bree: Scheduled jobs run periodically
Bree->>Stripe: Get all customers & subscriptions
Stripe-->>Bree: Return customer data
Bree->>DB: Compare & reconcile data
Bree->>PayPal: Get all subscriptions & transactions
PayPal-->>Bree: Return subscription data
Bree->>DB: Compare & reconcile data
%% Edge case: Dispute handling
Note over User,PayPal: User disputes a charge
PayPal->>FE: DISPUTE.CREATED webhook
FE->>PayPal: Accept claim automatically
FE->>DB: Update user status
FE->>User: Send notification email
2계층: 서명 검증이 포함된 웹훅 핸들러
결제 후 리디렉션은 대부분 시나리오에서 잘 작동하지만 완벽하지는 않습니다. 사용자는 리디렉션되기 전에 브라우저를 닫을 수도 있고, 네트워크 문제로 인해 리디렉션이 완료되지 않을 수도 있습니다. 여기서 웹훅이 등장합니다.
Stripe와 PayPal은 모두 결제 이벤트에 대한 실시간 알림을 보내는 웹훅 시스템을 제공합니다. 우리는 이러한 알림의 진위성을 확인하고 그에 따라 처리하는 강력한 웹훅 핸들러를 구현했습니다.
Stripe 웹훅 구현
Stripe 웹훅 핸들러는 들어오는 웹훅 이벤트의 서명을 검증하여 합법적인지 확인합니다.
async function webhook(ctx) {
const sig = ctx.request.get('stripe-signature');
// throw an error if something was wrong
if (!isSANB(sig))
throw Boom.badRequest(ctx.translateError('INVALID_STRIPE_SIGNATURE'));
const event = stripe.webhooks.constructEvent(
ctx.request.rawBody,
sig,
env.STRIPE_ENDPOINT_SECRET
);
// throw an error if something was wrong
if (!event)
throw Boom.badRequest(ctx.translateError('INVALID_STRIPE_SIGNATURE'));
ctx.logger.info('stripe webhook', { event });
// return a response to acknowledge receipt of the event
ctx.body = { received: true };
// run in background
processEvent(ctx, event)
.then()
.catch((err) => {
ctx.logger.fatal(err, { event });
// email admin errors
emailHelper({
template: 'alert',
message: {
to: config.email.message.from,
subject: `Error with Stripe Webhook (Event ID ${event.id})`
},
locals: {
message: `<pre><code>${safeStringify(
parseErr(err),
null,
2
)}</code></pre>`
}
})
.then()
.catch((err) => ctx.logger.fatal(err, { event }));
});
}
그만큼 stripe.webhooks.constructEvent 함수는 엔드포인트 비밀을 사용하여 서명을 검증합니다. 서명이 유효하면 웹훅 응답을 차단하지 않기 위해 이벤트를 비동기적으로 처리합니다.
PayPal 웹훅 구현
마찬가지로, PayPal 웹훅 핸들러는 들어오는 알림의 진위성을 확인합니다.
async function webhook(ctx) {
const response = await promisify(
paypal.notification.webhookEvent.verify,
paypal.notification.webhookEvent
)(ctx.request.headers, ctx.request.body, env.PAYPAL_WEBHOOK_ID);
// throw an error if something was wrong
if (!_.isObject(response) || response.verification_status !== 'SUCCESS')
throw Boom.badRequest(ctx.translateError('INVALID_PAYPAL_SIGNATURE'));
// return a response to acknowledge receipt of the event
ctx.body = { received: true };
// run in background
processEvent(ctx)
.then()
.catch((err) => {
ctx.logger.fatal(err);
// email admin errors
emailHelper({
template: 'alert',
message: {
to: config.email.message.from,
subject: `Error with PayPal Webhook (Event ID ${ctx.request.body.id})`
},
locals: {
message: `<pre><code>${safeStringify(
parseErr(err),
null,
2
)}</code></pre>`
}
})
.then()
.catch((err) => ctx.logger.fatal(err));
});
}
두 웹훅 핸들러는 모두 동일한 패턴을 따릅니다. 서명을 확인하고, 수신을 확인하고, 이벤트를 비동기적으로 처리합니다. 이렇게 하면 결제 후 리디렉션이 실패하더라도 결제 이벤트를 절대 놓치지 않습니다.
3계층: Bree를 사용한 자동화된 작업
트리펙타 접근 방식의 마지막 계층은 결제 데이터를 주기적으로 검증하고 조정하는 자동화된 작업 세트입니다. Node.js용 작업 스케줄러인 Bree를 사용하여 이러한 작업을 정기적으로 실행합니다.
구독 정확도 검사기
우리의 주요 작업 중 하나는 구독 정확도 검사기로, 이를 통해 데이터베이스가 Stripe의 구독 상태를 정확하게 반영하는지 확인합니다.
async function mapper(customer) {
// wait a second to prevent rate limitation error
await setTimeout(ms('1s'));
// check for user on our side
let user = await Users.findOne({
[config.userFields.stripeCustomerID]: customer.id
})
.lean()
.exec();
if (!user) return;
if (user.is_banned) return;
// if emails did not match
if (user.email !== customer.email) {
logger.info(
User email ${user.email} did not match customer email ${customer.email} (${customer.id})
);
customer = await stripe.customers.update(customer.id, {
email: user.email
});
logger.info(Updated user email to match ${user.email});
}
// check for active subscriptions
const [activeSubscriptions, trialingSubscriptions] = await Promise.all([
stripe.subscriptions.list({
customer: customer.id,
status: 'active'
}),
stripe.subscriptions.list({
customer: customer.id,
status: 'trialing'
})
]);
// Combine active and trialing subscriptions
let subscriptions = [
...activeSubscriptions.data,
...trialingSubscriptions.data
];
// Handle edge case: multiple subscriptions for one user
if (subscriptions.length > 1) {
await logger.error(
new Error(
We may need to refund: User had multiple subscriptions ${user.email} (${customer.id})
)
);
await emailHelper({
template: 'alert',
message: {
to: config.email.message.from,
subject: User had multiple subscriptions ${user.email}
},
locals: {
message: User ${user.email} (${customer.id}) had multiple subscriptions: ${JSON.stringify( subscriptions.map((s) => s.id) )}
}
});
}
}
이 작업은 이메일 주소 불일치나 여러 활성 구독과 같은 데이터베이스와 Stripe 간의 불일치를 확인합니다. 문제가 발견되면 이를 기록하고 관리 팀에 알림을 보냅니다.
PayPal 구독 동기화
PayPal 구독에 대해서도 비슷한 작업이 있습니다.
async function syncPayPalSubscriptionPayments() {
const paypalCustomers = await Users.find({
$or: [
{
[config.userFields.paypalSubscriptionID]: { $exists: true, $ne: null }
},
{
[config.userFields.paypalPayerID]: { $exists: true, $ne: null }
}
]
})
// sort by newest customers first
.sort('-created_at')
.lean()
.exec();
await logger.info(
Syncing payments for ${paypalCustomers.length} paypal customers
);
// Process each customer and sync their payments
const errorEmails = await pReduce(
paypalCustomers,
// Implementation details...
);
}
이러한 자동화된 작업은 Stripe와 PayPal의 구독 및 결제의 실제 상태를 항상 데이터베이스가 반영하도록 보장하여 최종적인 안전망 역할을 합니다.
엣지 케이스 처리
강력한 결제 시스템은 예외 상황을 우아하게 처리해야 합니다. 몇 가지 일반적인 시나리오를 어떻게 처리하는지 살펴보겠습니다.
사기 탐지 및 예방
우리는 의심스러운 결제 활동을 자동으로 식별하고 처리하는 정교한 사기 감지 메커니즘을 구현했습니다.
case 'charge.failed': {
// Get all failed charges in the last 30 days
const charges = await stripe.charges.list({
customer: event.data.object.customer,
created: {
gte: dayjs().subtract(1, 'month').unix()
}
});
// Filter for declined charges
const filtered = charges.data.filter(
(d) => d.status === 'failed' && d.failure_code === 'card_declined'
);
// if not more than 5 then return early
if (filtered.length < 5) break;
// Check if user has verified domains
const count = await Domains.countDocuments({
members: {
$elemMatch: {
user: user._id,
group: 'admin'
}
},
plan: { $in: ['enhanced_protection', 'team'] },
has_txt_record: true
});
if (!user.is_banned) {
// If no verified domains, ban the user and refund all charges
if (count === 0) {
// Ban the user
user.is_banned = true;
await user.save();
// Refund all successful charges
}
}
}
이 코드는 결제 실패가 여러 번 있고 검증된 도메인이 없는 사용자를 자동으로 차단하는데, 이는 사기 활동의 강력한 지표입니다.
분쟁 처리
사용자가 요금에 대해 이의를 제기하는 경우, 당사는 자동으로 청구를 수락하고 적절한 조치를 취합니다.
case 'CUSTOMER.DISPUTE.CREATED': {
// accept claim
const agent = await paypalAgent();
await agent
.post(`/v1/customer/disputes/${body.resource.dispute_id}/accept-claim`)
.send({
note: 'Full refund to the customer.'
});
// Find the payment in our database
const payment = await Payments.findOne({ $or });
if (!payment) throw new Error('Payment does not exist');
const user = await Users.findById(payment.user);
if (!user) throw new Error('User did not exist for customer');
// Cancel the user's subscription if they have one
if (isSANB(user[config.userFields.paypalSubscriptionID])) {
try {
const agent = await paypalAgent();
await agent.post(
/v1/billing/subscriptions/${ user[config.userFields.paypalSubscriptionID] }/cancel
);
} catch (err) {
// Handle subscription cancellation errors
}
}
}
이러한 접근 방식은 고객에게 좋은 경험을 보장하는 동시에 분쟁이 당사 사업에 미치는 영향을 최소화합니다.
코드 재사용: KISS 및 DRY 원칙
결제 시스템 전반에 걸쳐 KISS(Keep It Simple, Stupid) 및 DRY(Don't Repeat Yourself) 원칙을 고수했습니다. 몇 가지 예를 들면 다음과 같습니다.
-
공유 헬퍼 기능: 결제 동기화, 이메일 전송 등의 일반적인 작업을 위해 재사용 가능한 도우미 기능을 만들었습니다.
-
일관된 오류 처리: Stripe와 PayPal 웹훅 핸들러는 모두 오류 처리 및 관리자 알림에 동일한 패턴을 사용합니다.
-
통합 데이터베이스 스키마: 당사의 데이터베이스 스키마는 Stripe와 PayPal 데이터를 모두 수용하도록 설계되었으며, 결제 상태, 금액, 요금제 정보에 대한 공통 필드를 갖추고 있습니다.
-
중앙 집중식 구성: 결제 관련 구성은 단일 파일에 중앙 집중화되어 있어 가격 및 제품 정보를 쉽게 업데이트할 수 있습니다.
graph TD
subgraph "Code Reuse Patterns"
A[Helper Functions] --> B[syncStripePaymentIntent]
A --> C[syncPayPalOrderPaymentByPaymentId]
A --> D[syncPayPalSubscriptionPaymentsByUser]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
graph TD
subgraph "Code Reuse Patterns"
E[Error Handling] --> F[Common Error Logging]
E --> G[Admin Email Notifications]
E --> H[User Notifications]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
graph TD
subgraph "Code Reuse Patterns"
I[Configuration] --> J[Centralized Payment Config]
I --> K[Shared Environment Variables]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
graph TD
subgraph "Code Reuse Patterns"
L[Webhook Processing] --> M[Signature Verification]
L --> N[Async Event Processing]
L --> O[Background Processing]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
graph TD
subgraph "KISS Principle"
P[Simple Data Flow] --> Q[Unidirectional Updates]
P --> R[Clear Responsibility Separation]
S[Explicit Error Handling] --> T[No Silent Failures]
S --> U[Comprehensive Logging]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
graph TD
subgraph "DRY Principle"
V[Shared Logic] --> W[Payment Processing Functions]
V --> X[Email Templates]
V --> Y[Validation Logic]
Z[Common Database Operations] --> AA[User Updates]
Z --> AB[Payment Recording]
end
classDef primary fill:blue,stroke:#333,stroke-width:2px;
classDef secondary fill:red,stroke:#333,stroke-width:1px;
class A,P,V primary;
class B,C,D,E,I,L,Q,R,S,W,X,Y,Z secondary;
VISA 구독 요구 사항 구현
트리펙타 접근 방식 외에도 VISA의 구독 요구 사항을 준수하고 사용자 경험을 개선하기 위한 특정 기능을 구현했습니다. VISA의 핵심 요구 사항 중 하나는 특히 체험판에서 유료 구독으로 전환할 때 구독료가 청구되기 전에 사용자에게 알림을 보내야 한다는 것입니다.
자동 갱신 전 이메일 알림
우리는 활성 체험 구독이 있는 사용자를 식별하고 첫 번째 요금이 청구되기 전에 알림 이메일을 보내는 자동화된 시스템을 구축했습니다. 이를 통해 VISA 요구 사항을 준수할 수 있을 뿐만 아니라 환불을 줄이고 고객 만족도를 개선할 수 있습니다.
이 기능을 구현한 방법은 다음과 같습니다.
// Find users with trial subscriptions who haven't received a notification yet
const users = await Users.find({
$or: [
{
$and: [
{ [config.userFields.stripeSubscriptionID]: { $exists: true } },
{ [config.userFields.stripeTrialSentAt]: { $exists: false } },
// Exclude subscriptions that have already had payments
...(paidStripeSubscriptionIds.length > 0
? [
{
[config.userFields.stripeSubscriptionID]: {
$nin: paidStripeSubscriptionIds
}
}
]
: [])
]
},
{
$and: [
{ [config.userFields.paypalSubscriptionID]: { $exists: true } },
{ [config.userFields.paypalTrialSentAt]: { $exists: false } },
// Exclude subscriptions that have already had payments
...(paidPayPalSubscriptionIds.length > 0
? [
{
[config.userFields.paypalSubscriptionID]: {
$nin: paidPayPalSubscriptionIds
}
}
]
: [])
]
}
]
});
// Process each user and send notification
for (const user of users) {
// Get subscription details from payment processor
const subscription = await getSubscriptionDetails(user);
// Calculate subscription duration and frequency
const duration = getDurationFromPlanId(subscription.plan_id);
const frequency = getHumanReadableFrequency(duration, user.locale);
const amount = getPlanAmount(user.plan, duration);
// Get user's domains for personalized email
const domains = await Domains.find({
'members.user': user._id
}).sort('name').lean().exec();
// Send VISA-compliant notification email
await emailHelper({
template: 'visa-trial-subscription-requirement',
message: {
to: user.receipt_email || user.email,
...(user.receipt_email ? { cc: user.email } : {})
},
locals: {
user,
firstChargeDate: new Date(subscription.start_time),
frequency,
formattedAmount: numeral(amount).format('$0,0,0.00'),
domains
}
});
// Record that notification was sent
await Users.findByIdAndUpdate(user._id, {
$set: {
[config.userFields.paypalTrialSentAt]: new Date()
}
});
}
이 구현을 통해 사용자는 다음에 대한 명확한 세부 정보와 함께 예정된 요금에 대해 항상 알 수 있습니다.
- 첫 번째 요금이 발생하는 시점
- 향후 청구 빈도(월별, 연간 등)
- 정확히 얼마의 금액이 청구될 것인가
- 구독에 포함되는 도메인은 무엇입니까?
이 프로세스를 자동화함으로써 VISA의 요구 사항(청구하기 최소 7일 전에 통지해야 함)을 완벽하게 준수하는 동시에 지원 문의를 줄이고 전반적인 사용자 경험을 개선할 수 있습니다.
엣지 케이스 처리
당사의 구현에는 견고한 오류 처리도 포함됩니다. 알림 프로세스 중에 문제가 발생하면 당사 시스템은 자동으로 당사 팀에 다음과 같이 경고합니다.
try {
await mapper(user);
} catch (err) {
logger.error(err);
// Send alert to administrators
await emailHelper({
template: 'alert',
message: {
to: config.email.message.from,
subject: 'VISA Trial Subscription Requirement Error'
},
locals: {
message: <pre><code>${safeStringify( parseErr(err), null, 2 )}</code></pre>
}
});
}
이를 통해 알림 시스템에 문제가 발생하더라도 당사 팀은 신속하게 문제를 해결하고 VISA 요구 사항을 준수할 수 있습니다.
VISA 구독 알림 시스템은 규정 준수와 사용자 경험을 모두 염두에 두고 결제 인프라를 구축한 방법의 또 다른 사례로, 안정적이고 투명한 결제 처리를 보장하기 위한 3중 접근 방식을 보완합니다.
체험 기간 및 구독 약관
기존 요금제에서 자동 갱신을 활성화한 사용자의 경우 현재 요금제가 만료될 때까지 요금이 청구되지 않도록 적절한 체험 기간을 계산합니다.
if (
isEnableAutoRenew &&
dayjs(ctx.state.user[config.userFields.planExpiresAt]).isAfter(
dayjs()
)
) {
const hours = dayjs(
ctx.state.user[config.userFields.planExpiresAt]
).diff(dayjs(), 'hours');
// Handle trial period calculation
}
또한 청구 빈도와 취소 정책을 포함한 구독 약관에 대한 명확한 정보를 제공하며, 적절한 추적 및 관리를 보장하기 위해 각 구독에 대한 자세한 메타데이터를 포함합니다.
결론: 우리의 Trifecta 접근법의 이점
결제 처리에 대한 당사의 3중 접근 방식은 여러 가지 주요 이점을 제공했습니다.
-
신뢰할 수 있음: 3단계의 결제 검증을 구현하여 결제가 누락되거나 잘못 처리되는 일이 없도록 보장합니다.
-
정확성: 당사 데이터베이스는 항상 Stripe와 PayPal의 구독 및 결제의 실제 상태를 반영합니다.
-
유연성: 사용자는 시스템의 안정성을 손상시키지 않고도 선호하는 결제 방법을 선택할 수 있습니다.
-
견고성: 당사 시스템은 네트워크 장애부터 사기 행위까지 예외적인 상황을 원활하게 처리합니다.
여러 프로세서를 지원하는 결제 시스템을 구현하는 경우 이 트리펙타 방식을 적극 권장합니다. 더 많은 사전 개발 노력이 필요하지만 신뢰성과 정확성 측면에서 장기적 이점이 충분히 가치가 있습니다.
Forward Email 및 개인정보 보호 중심 이메일 서비스에 대한 자세한 내용은 다음을 방문하세요. 웹사이트.