גישת Trifecta: כיצד הועברו דוא"ל בנה מערכת תשלום חסינת כדורים עם Stripe ו-PayPal

הַקדָמָה

ב-Forward Email, תמיד נתנו עדיפות ליצירת מערכות אמינות, מדויקות וידידותיות למשתמש. כשזה הגיע להטמעת מערכת עיבוד התשלומים שלנו, ידענו שאנחנו צריכים פתרון שיוכל להתמודד עם מספר מעבדי תשלומים תוך שמירה על עקביות נתונים מושלמת. פוסט זה בבלוג מפרט כיצד צוות הפיתוח שלנו שילב גם את Stripe וגם את PayPal תוך שימוש בגישת trifecta שמבטיחה דיוק של 1:1 בזמן אמת בכל המערכת שלנו.
האתגר: מעבדי תשלומים מרובים, מקור אחד של אמת

כשירות דוא"ל ממוקד פרטיות, רצינו לתת למשתמשים שלנו אפשרויות תשלום. יש המעדיפים את הפשטות של תשלומים בכרטיס אשראי דרך Stripe, בעוד שאחרים מעריכים את שכבת ההפרדה הנוספת ש-PayPal מספקת. עם זאת, תמיכה במספר מעבדי תשלומים מציגה מורכבות משמעותית:
כיצד נבטיח נתונים עקביים במערכות תשלום שונות?
כיצד אנו מטפלים במקרים קצה כמו מחלוקות, החזרים כספיים או תשלומים כושלים?
כיצד נשמור על מקור אמת אחד במסד הנתונים שלנו?
הפתרון שלנו היה ליישם את מה שאנו מכנים "גישת trifecta" - מערכת תלת-שכבתית המספקת יתירות ומבטיחה עקביות נתונים לא משנה מה יקרה.
גישת הטריפקטה: שלוש שכבות של אמינות

מערכת התשלומים שלנו מורכבת משלושה מרכיבים קריטיים הפועלים יחד כדי להבטיח סנכרון נתונים מושלם:
הפניות מחדש לאחר התשלום - לכידת פרטי תשלום מיד לאחר התשלום
מטפלי Webhook - עיבוד אירועים בזמן אמת ממעבדי תשלומים
עבודות אוטומטיות - אימות והתאמה תקופתית של נתוני תשלום
בואו נצלול לתוך כל רכיב ונראה איך הם עובדים יחד.
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 &#x26; reconcile| Database
    PayPalSync --> |Verify &#x26; 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 &#x26; 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: הפניות לאחר צ'ק-אאוט
השכבה הראשונה של גישת ה-trifecta שלנו מתרחשת מיד לאחר שמשתמש משלים תשלום. הן Stripe והן PayPal מספקות מנגנונים להפנות משתמשים חזרה לאתר שלנו עם פרטי עסקאות.
יישום Stripe Checkout
עבור Stripe, אנו משתמשים ב-Checkout Sessions API שלהם כדי ליצור חווית תשלום חלקה. כאשר משתמש בוחר תוכנית ובוחר לשלם בכרטיס אשראי, אנו יוצרים סשן צ'ק-אאוט עם הצלחה ספציפית ומבטלים כתובות אתרים:
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 מפנה את המשתמש חזרה לאתר שלנו לאחר תשלום מוצלח, אנו יכולים להשתמש במזהה הפעלה זה כדי לאמת את העסקה ולעדכן את מסד הנתונים שלנו בהתאם.
זרימת תשלום 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 &#x26; 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 &#x26; 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 &#x26; 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 &#x26; 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 &#x26; update data
    FE-->>PayPal: Acknowledge receipt (200 OK)
end

%% Bree automated jobs
Note over Bree: Scheduled jobs run periodically

Bree->>Stripe: Get all customers &#x26; subscriptions
Stripe-->>Bree: Return customer data
Bree->>DB: Compare &#x26; reconcile data

Bree->>PayPal: Get all subscriptions &#x26; transactions
PayPal-->>Bree: Return subscription data
Bree->>DB: Compare &#x26; 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: מטפלי Webhook עם אימות חתימה
בעוד שהפניות מחדש לאחר התשלום פועלות היטב עבור רוב התרחישים, הן אינן חסינות תקלות. משתמשים עלולים לסגור את הדפדפן שלהם לפני ניתוב מחדש, או שבעיות רשת עלולות למנוע את השלמת ההפניה מחדש. זה המקום שבו webhooks נכנסים לתמונה.
גם Stripe וגם PayPal מספקות מערכות webhook ששולחות התראות בזמן אמת על אירועי תשלום. הטמענו מטפלי webhook חזקים שמאמתים את האותנטיות של הודעות אלה ומעבדים אותן בהתאם.
יישום Stripe Webhook
מטפל ה-Stripe webhook שלנו מאמת את החתימה של אירועי webhook נכנסים כדי להבטיח שהם לגיטימיים:
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 הפונקציה מאמתת את החתימה באמצעות סוד נקודת הקצה שלנו. אם החתימה חוקית, אנו מעבדים את האירוע באופן אסינכרוני כדי למנוע חסימת תגובת ה-webhook.
יישום Webhook של PayPal
באופן דומה, המטפל שלנו ב-Webhook של 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));
    });
}

שני המטפלים ב-webhook עוקבים אחר אותו דפוס: אמת את החתימה, אשר קבלה ועבד את האירוע באופן אסינכרוני. זה מבטיח שלעולם לא נחמיץ אירוע תשלום, גם אם ההפניה מחדש לאחר התשלום נכשלת.
שכבה 3: עבודות אוטומטיות עם Bree
השכבה האחרונה של גישת ה-trifecta שלנו היא קבוצה של עבודות אוטומטיות המאמתות ומתאמות מדי פעם את נתוני התשלום. אנו משתמשים ב-Bree, מתזמן משימות עבור Node.js, כדי להפעיל את המשימות הללו במרווחי זמן קבועים.
בודק דיוק מנויים
אחת מתפקידי המפתח שלנו היא בודק דיוק המנויים, המבטיח שמסד הנתונים שלנו משקף במדויק את סטטוס המנוי ב-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). הנה כמה דוגמאות:


פונקציות עוזר משותפות: יצרנו פונקציות עוזר לשימוש חוזר למשימות נפוצות כמו סנכרון תשלומים ושליחת אימיילים.


טיפול עקבי בשגיאות: גם מטפלי webhook של 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
בנוסף לגישת ה-trifecta שלנו, הטמענו תכונות ספציפיות כדי לעמוד בדרישות המנוי של 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: &#x3C;pre>&#x3C;code>${safeStringify(         parseErr(err),         null,         2       )}&#x3C;/code>&#x3C;/pre>
}
});
}

זה מבטיח שגם אם יש בעיה במערכת ההתראות, הצוות שלנו יכול לטפל בה במהירות ולשמור על עמידה בדרישות של VISA.
מערכת ההודעות על מנוי VISA היא דוגמה נוספת לאופן שבו בנינו את תשתית התשלומים שלנו תוך מחשבה על ציות וחווית משתמש, משלימה את גישת ה-trifecta שלנו כדי להבטיח עיבוד תשלומים אמין ושקוף.
תקופות ניסיון ותנאי מנוי
עבור משתמשים המאפשרים חידוש אוטומטי בתוכניות קיימות, אנו מחשבים את תקופת הניסיון המתאימה כדי להבטיח שהם לא יחויבו עד שתוקף התוכנית הנוכחית שלהם יפוג:
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
}

אנו גם מספקים מידע ברור על תנאי המנוי, כולל תדירות חיוב ומדיניות ביטולים, וכוללים מטא נתונים מפורטים עם כל מנוי כדי להבטיח מעקב וניהול נאותים.
מסקנה: היתרונות של גישת הטריפקטה שלנו
גישת הטריפקטה שלנו לעיבוד תשלומים סיפקה מספר יתרונות מרכזיים:


אֲמִינוּת: על ידי הטמעת שלוש שכבות של אימות תשלום, אנו מבטיחים שאף תשלום לא מוחמצן או מעובד בצורה שגויה.


דִיוּק: מסד הנתונים שלנו תמיד משקף את המצב האמיתי של מנויים ותשלומים גם ב-Stripe וגם ב-PayPal.


גְמִישׁוּת: משתמשים יכולים לבחור את שיטת התשלום המועדפת עליהם מבלי לפגוע באמינות המערכת שלנו.


איתנות: המערכת שלנו מטפלת במקרים קצה בחן, החל מתקלות ברשת ועד לפעילויות הונאה.


אם אתה מיישם מערכת תשלומים התומכת במספר מעבדים, אנו ממליצים בחום על גישת trifecta זו. זה דורש יותר מאמצי פיתוח מראש, אבל היתרונות ארוכי הטווח מבחינת אמינות ודיוק שווים את זה.
למידע נוסף על Forward Email ושירותי הדוא"ל הממוקדים בפרטיות שלנו, בקר באתר שלנו אֲתַר אִינטֶרנֶט.