🚨 Stripe HackerRank OA 深度拆解：Merchant Fraud Scoring System —— 看似简单的业务逻辑题，为何翻车率奇高？

在北美大厂的 Online Assessment 中，Stripe 一直是一个非常特殊的存在。

相比常规算法公司，Stripe 的 OA 更偏向真实业务场景，题面冗长、规则复杂、实现细节极多，往往一小时只给一题，却能完整考察候选人对业务逻辑拆解和工程实现能力的理解。

这篇文章将结合一次完整实战，系统拆解 Stripe HackerRank Online Assessment Questions 的典型模型，总结其隐藏的出题套路与稳定解法，帮助你在有限时间内快速建立清晰的解题结构。

📋 Stripe HackerRank OA 真题：Merchant Fraud Scoring System

题目模拟 Stripe 的 merchant fraud scoring system，目标很明确：

根据一天内的交易记录和对应的规则，为每个 merchant 计算最终的欺诈分数，并按 merchant 名字字典序输出结果。

输入结构

输入会给你三样东西：

1. transactions_list
   一天内的所有交易记录

2. rules_list
   与 transactions 一一对应的规则列表

3. merchants_list
   每个 merchant 都有一个 base_score 初始分数

注意一个非常重要的点：
transactions 和 rules 是严格一一对应的，这个信息在后面实现中非常关键。

🎯 整体解题思路

这题千万不要一条 transaction 一条 transaction 直接算分，否则逻辑会极其混乱。

正确的做法是：按规则类型分阶段处理，先收集状态，再统一结算。

我个人会拆成五个明确步骤。

Step 1：先把 merchants 建成字典

第一步不要急着算分，先把 merchants_list 拆成一个字典结构：

merchant_id -> current_score

其中 current_score 初始化为 base_score。

后面所有规则，都是在 current_score 的基础上进行乘法或加减。

Step 2：合并 transaction 和 rule 成完整记录

由于 transactions_list 和 rules_list 一一对应，强烈建议在一开始就做合并处理。

每条完整记录至少包含以下字段：

• merchant_id
• customer_id
• amount
• hour
• min_transaction_amount
• multiplicative_factor
• additive_factor
• penalty

这样后面所有逻辑都只围绕一个 records 列表展开，避免在多个数组之间来回索引，非常容易出错。

Step 3：第一轮遍历，处理金额乘法规则

这一轮是全题最基础的一步，但也有一个容易被忽略的坑。

规则是：

如果 transaction_amount > min_transaction_amount
就将 merchant 的 current_score 乘以对应的 multiplicative_factor。

注意几点：

• 是严格大于，而不是大于等于
• 每一笔 transaction 都要单独判断
• 这是直接更新 merchant 的 current_score

这一轮只做乘法，不处理任何加分或扣分逻辑。

Step 4：第二轮，customer + merchant 的 additive 规则

这是 Stripe 非常典型、也最爱考的一类规则。

规则描述是：

如果同一个 customer_id 对同一个 merchant_id 的交易次数达到 3 次或以上（包含当前交易），
那么该组内每一笔交易的 additive_factor 都要累加到 merchant 的 current_score 上。

官方题面中特意强调了一点：

• 第三笔交易时的分数已经包含前 1、2、3 笔的 additive；
• 第四笔交易时，是在此基础上再加上第四笔的 additive_factor。

因此这里的正确做法是：

1. 按 (merchant_id, customer_id) 分组
2. 统计交易次数
3. 如果 count >= 3
   就把该组内所有 additive_factor 求和
4. 一次性加到对应 merchant 的 current_score 上

不要在单条 transaction 里即时加，否则非常容易重复计算。

Step 5：第三轮，同小时交易的 penalty 规则

这是全题最绕、最容易写错的一部分。

触发条件是：

• 同一个 customer_id
• 同一个 merchant_id
• 同一个 hour
• 交易次数达到 3 次或以上（包含当前）

注意：
一旦达到 3 次，处罚或奖励是对这一小时内的所有交易都生效，包括第 1、2 笔。

不同时间段对应不同操作

如果 hour 在 12 到 17（含）之间
每一笔交易都要加 penalty

如果 hour 在 9 到 11，或者 18 到 21（含）之间
每一笔交易都要减 penalty

如果 hour 不在上述区间
什么都不做

推荐实现方式

和 additive 规则一样：

1. 按 (merchant_id, customer_id, hour) 分组
2. count >= 3 才触发
3. 将 penalty 乘以该组交易次数
4. 根据 hour 区间决定是加还是减
5. 最后一次性更新 merchant 的 current_score

Step 6：排序并输出结果

最后一步是输出处理：

• 按 merchant 名字字典序排序
• 输出格式严格为：

name, score

HackerRank 对格式要求非常严格，多一个空格或少一个逗号都有可能直接判错。

💡 这道题本质在考什么

这题本质不是算法题，而是：

• 复杂业务规则拆解能力
• 多维状态统计能力
• 分阶段累计而不是即时计算
• 工程化实现和代码组织能力

如果一边读题一边写，很容易在中途发现状态完全控不住。

🚀 想在 OA / VO 中脱颖而出？oavoservice 提供全方位面试护航服务

无论是 OA 代刷、VO 实时辅助，还是面试助攻，我们的北美 CS 专家都能为你提供实时提示和思路，效果远超 AI。

代面试、SDE 代面、FAANG 代面？没问题。

通过摄像头转接与变声技术，我们的专业团队帮你完成全程面试。提前模拟测试、配合默契，你的脸合成我们的声音，现场表现自信自然，无缝衔接。

全套包过、Offer 包拿、快速入职大厂。

无论是 OA、面试、还是签约谈判，我们全程护航，直到你拿到满意 Offer。

服务采用预付少量定金、拿到 Offer 后支付尾款模式，让你无后顾之忧。

We consistently provide professional online assessment and interview assistance services for major tech companies like TikTok, Google, and Amazon, guaranteeing perfect scores and successful outcomes.

👉 立即添加微信：Coding0201

锁定你的 Stripe Offer 机会！