★ FEATURED ARTICLE 简介一套完整的海外信贷/贷款平台源码适合有Laravel基础的开发者、借贷系统外包团队或金融科技公司用于快速搭建线上放款与风控业务。基于Laravel框架支持中英文双语覆盖借款申请、授信审核、还款管理等核心流程既可直接部署也可按业务二次开发。压缩包共2000个文件大小约181.82MB其中JS脚本1338个、JSON配置文件218个、Markdown文档179个、CSS样式148个、HTML页面103个另有SQL数据库脚本与少量文本、XML文件基本涵盖后端逻辑、前端页面、项目说明和数据库初始化内容。部署要求已明确Linux CentOS7.6、宝塔、PHP7.3、MySQL5.6根目录指向public采用Laravel5伪静态并开启SSL证书数据库连接只需修改根目录.env文件。已有377人学习下载资源内提供编译后的前端入口、AdminLTE后台主题、Laravel模块化目录及多语言文案能帮助理解海外借贷平台的目录组织、前后端分离和上线配置思路减少从零搭建的重复工作。1. 海外贷款平台源码先搞清楚贷的是什么再谈买谁的代码一套海外贷款信贷产品源码拿到手大家最先试的永远是注册、进件、放款这一条主链路能不能跑通。但真正做过几单业务之后你大概率会在某个深夜被对不上的账目砸醒还款计划少算一期、提前还款后本金对不上、逾期罚息和催收节点各算各的。支撑一个海外借贷平台长期运转的不是原来那个管理后台美不美观而是产品参数化和账务内核——同一套代码能不能同时开出现金贷、分期、BNPL 几种线上贷款产品每个产品的利率期限、还款方式、逾期规则改配置就行不动一行业务代码。这篇稿子写给三类人打算采购贷款平台软件源码的技术负责人、正在自研海外信贷系统的开发团队、以及想搞懂线上贷款产品完整模块的从业者。2. 线上贷款产品大全从现金贷到 BNPL每个产品形态都对应一套账务模型先别急着翻代码。我给不少团队做过系统落地第一课永远是产品形态梳理。因为源码仓库里所有模块本质上都是为某一种产品形态服务的用现金贷的逻辑去套分期产品账务上会错得离谱。线上贷款产品看上去名字花哨拆到底就是四种账务模型的组合。2.1 现金贷、分期、BNPL、随借随还四种产品形态的账务差异现金贷短周期小额度最常见的还款方式是到期一次性还本付息一笔借款只有一笔应还金额账务最简单但逾期率也最高分期贷款消费分期、大额分期使用等额本息或等额本金摊还每一期按计划拆本金和利息还涉及服务费、保险费等附加项BNPL先买后付表面是零息分期真实账务是商家补贴利息消费者端每期只还本金逾期后开始生成罚息所以账务上要区分正常期和违约期随借随还循环额度按日计息、随借随还用户有授信额度借一笔生成一笔子合同额度实时恢复账务上要额外管理额度台账。产品形态计息方式还款方式账务核心现金贷到期一次性利息一次性还本付息金额小、账期短本金利息一笔结消费分期名义年化摊还等额本息/等额本金每期拆本金利息服务费BNPL商家补贴利息分期还本金正常期零息逾期转罚息随借随还按日计息任意金额还款额度台账多笔子合同并行我见过最常翻车的地方是把 BNPL 当成免息产品不做利息科目结果商家补贴一到账就成坏账也见过把随借随还做成固定分期导致用户提前还完款额度不恢复。买源码之前先拿这四种产品形态逐一对照你的业务计划看看这套代码底子支持几种。2.2 贷款平台的最小完整功能清单从进件到结清有哪些节点一套能上线运营的贷款平台无论源码写得多花哨功能上绕不开这几个节点进件借款人提交资料、APP 或 H5 表单、授信规则引擎自动审批或人工审核、签约电子合同签署、生成还款计划、放款对接资金方或支付通道打款、还款主动还款、银行卡代扣、钱包扣款、贷后逾期扫描、催收提醒、展期、提前结清、核销坏账处理、账务封账。每个节点都不是孤立的它落在订单状态机里。从贷款平台软件源码的视角看你只需要确认一件事这七个节点的状态流转是否有独立的领域表而不是硬编码在页面流程里。比如订单表里要有 APPLY、APPROVED、DISBURSED、REPAYING、OVERDUE、SETTLED、WRITTEN_OFF 这些状态还款计划表要有 UNPAID、PAID 状态。如果源码里连这些字段都没有那它只是个原型不是能跑钱的软件。2.3 还款计划的数学内核本金、利息、费用怎么拆才不出错所有账务问题的起点是一张正确的还款计划表。这里不是简单的本金除以期数再加利息而是要考虑摊还顺序、计息起点、四舍五入规则。下面是我在多个项目里反复用的一段生成等额本息还款计划的代码def amort_schedule(principal, annual_rate, months, installment_fee0.0): 等额本息还款计划生成器 :param principal: 放款本金单位元 :param annual_rate: 名义年利率如 0.18 表示 18% :param months: 分期期数 :param installment_fee: 每期服务费单位元 :return: 每期计划明细列表 monthly_rate annual_rate / 12.0 if monthly_rate 0: monthly_payment principal / months else: # 等额本息公式M P * r * (1r)^n / ((1r)^n - 1) factor (1 monthly_rate) ** months monthly_payment principal * monthly_rate * factor / (factor - 1) balance principal schedule [] for i in range(1, months 1): interest round(balance * monthly_rate, 2) principal_part round(monthly_payment - interest - installment_fee, 2) if i months: # 最后一期用剩余本金修正避免浮点尾差 principal_part round(balance, 2) balance round(balance - principal_part, 2) schedule.append({ period: i, due_payment: round(principal_part interest installment_fee, 2), principal_part: principal_part, interest: interest, installment_fee: installment_fee, balance_after: balance, }) return schedule这段代码的意图很明确把一笔贷款拆成每期应还的本金、利息和服务费并用最后一期修正浮点误差。注意两个关键设计——名义年利率要除以 12 得到月利率而不是用 360 天或实际天数服务费单独作为一列不要混进利率里否则提前还款时的费用减免逻辑很难写。还有一个隐蔽点等额本息的实际资金成本不等于名义利率因为本金在逐期减少你可以算一下 IRR会发现它约等于贷款总额一整年都占用的等价利率这对产品定价很关键。我一般会在产品配置里同时存名义利率和 IRR 两列方便运营对比。3. 贷款平台软件源码怎么选技术栈、目录结构、风控引擎的最小实现接下来解决最现实的问题钱该花在哪。在线下评估一套源码值不值时我不看页面截图只看三个东西——技术栈、数据库里有多少张账务表、风控规则是不是写死在业务代码里。3.1 技术栈选型Java、PHP、Node 分别适合什么团队市面上的贷款平台软件源码主流交付形态就三种JavaSpring Boot / Spring Cloud、PHPLaravel / ThinkPHP、Node.jsExpress / NestJS。Java 的优点是账务系统对事务处理扎实尤其适合同时跑多个贷款产品的核心系统但版本迭代慢PHP 胜在便宜、上线快很多现金贷源码都是 PHP 写的但账务精度和并发能力需要额外验证Node 在 IO 密集型场景好适合做渠道端接口层少见整库直接用 Node 跑核心账务。技术栈适合场景常见隐患团队要求Java / Spring Boot多产品线、复杂账务、长期运营启动重、开发效率略低需要熟悉事务隔离级别PHP / Laravel快速上线、单产品验证金额精度容易写成 float必须有强规范约束Node.js / NestJS渠道端、轻量进件流程账务并发下事务不好控制要有异步编程经验我这几年见过最典型的翻车是团队为了快速上线买了一整套 PHP 源码结果放款金额字段用了 float 类型账跑了一个月后对不上几块钱。买源码时一定要去代码里搜一下金额字段的类型定义看到 DOUBLE 或 FLOAT 直接砍价走人正确做法是 Java 的 BigDecimal、PHP 的 string 或 cent 整数存储。这也是为什么很多团队宁可要一套干净的 Laravel 框架代码自己改也不要半成品。3.2 读一套贷款源码先从目录结构和核心数据表下手拿到源码不要急着跑起来先用十五分钟把仓库目录结构过一遍。一套完整的贷款平台源码目录通常长这样loan-platform/ ├── admin-api/ # 管理端接口产品配置、订单管理、报表 ├── app-server/ # 借款端接口进件、签约、放款、还款 ├── job/ # 定时任务逾期扫描、代扣、催收提醒 ├── payment-adapter/ # 支付通道适配层放款、代扣、退款 ├── risk-engine/ # 风控决策规则集、评分卡对接 └── gateway/ # API 网关签名验签、限流这个结构的意义是业务接口、定时任务、支付适配、风控决策彼此分离后续改动时不会互相踩脚。看目录的同时顺手抓几张核心表的定义我一般先看这三张-- 借款申请/订单主表 CREATE TABLE loan_application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_code VARCHAR(32) NOT NULL, -- 产品编码关联产品配置表 user_id BIGINT NOT NULL, amount_cents BIGINT NOT NULL, -- 放款本金单位分 term INTEGER NOT NULL, -- 期数 status VARCHAR(16) NOT NULL, -- APPLY/APPROVED/DISBURSED/REPAYING/SETTLED created_at DATETIME NOT NULL ); -- 还款计划表 CREATE TABLE repayment_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, loan_id BIGINT NOT NULL, seq INTEGER NOT NULL, -- 第几期 due_date DATE NOT NULL, principal_cents BIGINT NOT NULL, -- 本期本金 interest_cents BIGINT NOT NULL, -- 本期利息 status VARCHAR(16) NOT NULL, -- UNPAID/PAID/OVERDUE paid_at DATETIME ); -- 交易流水表 CREATE TABLE transaction_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, loan_id BIGINT NOT NULL, biz_type VARCHAR(32) NOT NULL, -- LOAN/REPAY/ADJUST/REFUND/WRITE_OFF amount_cents BIGINT NOT NULL, balance_after_cents BIGINT NOT NULL, -- 该笔交易后的贷款余额 happened_at DATETIME NOT NULL );看这三张表核心是确认三点金额是不是以分为单位的整数、还款计划有没有独立表、交易流水有没有保留业务后的余额快照。前两点决定了账务会不会错位第三点决定了能不能对账。这里有一个血泪经验很多源码根本没有 transaction_log 表还款直接 UPDATE 订单状态这种代码跑一段时间后余额根本无从追溯资金对账靠手工 Excel建议直接放弃这种坑货。另外采购时一定让对方提供源码文件清单和目录结构说明很多团队要求附带软件著作权登记证书或者完整的代码交付清单这是确认源码完整度的最低门槛。3.3 风控引擎最小实现把决策规则从业务代码里抠出来一套贷款平台源码里最容易写死的地方就是风控。好一点的源码会提供规则引擎差一点的直接写几十个 if-else 散落在服务里。改利率还能忍改风控规则要发版本运营和技术的矛盾基本都从这里开始。我推荐的做法是把决策规则独立成配置至少做到规则参数和代码分离。# risk_rules.json 片段 { rules: [ {param: credit_score, op: , value: 620, action: APPROVE}, {param: monthly_income, op: , value: 300, action: REJECT}, {param: mobile_age_days, op: , value: 90, action: REJECT} ], fallback: MANUAL_REVIEW }import json def evaluate_risk(profile: dict, rules_path: str) - str: 读取规则文件逐条评估返回决策结果 with open(rules_path, r, encodingutf-8) as f: conf json.load(f) for rule in conf[rules]: val profile.get(rule[param]) if val is None: continue # 数据缺失该条不生效避免误杀 op rule[op] if op and val rule[value]: return rule[action] if op and val rule[value]: return rule[action] return conf[fallback]这个最小实现的意图是演示规则外置的思路每一条决策都是参数、比较符、阈值的组合业务上调整风控口径时只改 JSON不用改 Java 或 PHP 代码。注意一个关键点数据缺失时我用 continue也就是跳过而不是拒绝因为海外很多用户输入资料不完整一刀切拒绝会把好客户送给竞品。实际项目中你还会面临多条件组合、分数叠加、人工复核队列等需求但那都是在这套“规则外置”思路上的增量。如果源码里根本没有独立的风险引擎目录而是把风控写死在放款接口里这套源码的架构就停留在小作坊水平警惕后面延期和坏账同时找上门。4. 复刻 Home-credit 海外信贷产品的可配置借贷平台核心账务与三个最容易写错账的事件Home Credit 这类海外消费金融公司的打法核心不是单一产品而是让业务人员像配商品一样配置贷款产品利率、期限、还款方式、宽限期、提前还款规则全部参数化产品经理不碰代码就能发布新贷款产品。这一章我按这个思路拆解实现路径所有代码都围绕“可配置”展开。4.1 产品参数化产品配置表的设计与字段含义要做到产品可配置先要有一张足够细的产品配置表。这张表是连接业务和账务的桥梁字段设计直接决定你以后能不能灵活上新。CREATE TABLE product_config ( product_code VARCHAR(32) PRIMARY KEY, product_name VARCHAR(64) NOT NULL, min_amount_cents BIGINT NOT NULL, -- 最小放款金额分 max_amount_cents BIGINT NOT NULL, -- 最大放款金额分 min_term INTEGER NOT NULL, max_term INTEGER NOT NULL, annual_rate_bp INTEGER NOT NULL, -- 年化利率基点存储如 1800 表示 18% repayment_method VARCHAR(16) NOT NULL, -- EMI:等额本息 / ONE_TIME:一次性 / INTEREST_FIRST:先息后本 grace_days INTEGER NOT NULL DEFAULT 0, -- 还款宽限期天 overdue_daily_rate_bp INTEGER NOT NULL, -- 逾期日罚息率基点 prepayment_enabled BOOLEAN NOT NULL, -- 是否允许提前还款 extension_enabled BOOLEAN NOT NULL, -- 是否允许展期 fee_config JSON NOT NULL, -- 服务费/保险费等附加费用配置 status VARCHAR(16) NOT NULL DEFAULT ACTIVE );这是一张典型的消费金融产品参数表。两个最容易忽略的字段annual_rate_bp 用基点存储而不是小数是从根源避免浮点误差grace_days 宽限期独立成字段是因为很多海外市场还款日遇到节假日需要顺延硬编码在业务逻辑里每次都改得很痛苦。fee_config 用 JSON 存附加费用项比如“按放款金额 1.5% 收取服务费”“每期固定 2 美元账户管理费”既灵活又不需要频繁改表结构。实际操作中我把这张表的操作权限给到运营角色每次新上线产品只往里面插一行业务交付周期从两周压缩到一天。4.2 还款计划落地与逾期计算等额本息之外的边界处理有了产品配置表生成还款计划的逻辑就可以按 repayment_method 做分支。上一章已经给了等额本息的实现这里补全另外两个分支同时加上逾期罚息的计算。def gen_repayment_plan(principal_cents, product_config, start_date): method product_config[repayment_method] annual_rate product_config[annual_rate_bp] / 10000.0 term product_config[max_term] # 示例取最大期数实际按订单 if method ONE_TIME: plan [ { seq: 1, due_date: start_date timedelta(daysproduct_config[grace_days]), principal_cents: principal_cents, interest_cents: round(principal_cents * annual_rate * term / 12), } ] elif method INTEREST_FIRST: plan [] monthly_rate annual_rate / 12.0 for i in range(1, term 1): interest round(principal_cents * monthly_rate, 0) plan.append({ seq: i, due_date: start_date timedelta(days30 * i), principal_cents: principal_cents if i term else 0, interest_cents: interest, }) else: plan amort_schedule(principal_cents / 100.0, annual_rate, term) return plan def calc_overdue_fine(remain_amount_cents, overdue_days, daily_rate_bp): if overdue_days 0: return 0 rate daily_rate_bp / 10000.0 return round(remain_amount_cents * rate * overdue_days, 0)这段代码的意图是演示不同还款方式的分支处理。先息后本在海外现金贷和经营性贷款中很常见它名义利率远低于等额本息但资金一直全额占用所以逾期风险更高一次性还本付息的利息计算用 term/12 是因为整笔贷款只计息一期这里要注意 start_date 是放款日还是签约日的区别。逾期罚息计算有几个必须做死的规则罚息基数只含未还本金和利息不要滚入本金产生复利罚息率一般按日万分之几到万分之几十设定折算年化后要受当地利率上限约束逾期天数要从到期日次日开始计不要把宽限期算进去。4.3 提前还款、展期、借新还旧三个最容易写错账的事件账务系统的复杂性不在正常还款日而在异常事件。提前还款至少要处理三件事未到期利息是否全部减免、是否收取提前还款手续费、当期本金和利息的冲销顺序。展期的账务本质是重置还款计划把当前未还金额平摊到新的期数同时额外收取展期费这里最常见的坑是直接把原合同期限往后拉长导致账龄和逾期天数被隐藏。借新还旧则要小心双重放款旧合同未结清时新合同又放款两笔贷款同时处于 REPAYING 状态资金流向是旧订单归还款、新订单放款本质是用一笔信息流完成两笔资金流对账时永远要按合同号区分。提前还款的调整逻辑我建议用独立的事务函数来写def prepayment_settle(loan_id, prepayment_fee_bp0): # 1. 还原到当前日期所有未还本金余额 outstanding get_outstanding_principal(loan_id) # 2. 免收未到期利息只收本金 提前还款手续费 fee round(outstanding * prepayment_fee_bp / 10000.0, 0) # 3. 生成 SETTLED 状态记录减免利息金额 create_settle_transaction( loan_id, principaloutstanding, feefee, waived_interestget_unearned_interest(loan_id) )注意这个函数的执行前提是当前订单没有逾期。逾期订单的提前还款必须先冲逾期罚息再冲本金否则账上永远挂着一笔罚息。这里我再强调一次状态机的每个分支都要有唯一入口不要贷后模块里改状态、核心账务里也改状态两个地方改同一个字段早晚会出数据不一致。5. 海外借贷平台上线前的避坑清单征信、支付、数据安全的真实翻车点写系统不是把代码跑起来就完了接口联调和数据安全才是上线前的重头戏也是最容易翻车的地方。我按征信、支付、数据安全三条线把真实的踩坑记录整理出来。5.1 海外征信与第三方数据源对接评分卡边界与合规红线海外借贷平台的进件环节通常要接三类的数据身份真实性验证身份证件、手机号、运营商数据、征信评分当地征信局或第三方数据服务、黑名单反欺诈名单。对接时需要做成统一的数据源适配层因为每家服务商的字段格式和响应时间差异很大。评分卡的用法是在申请时取一次分再配合规则引擎做决策不要实时多次调用——会贵到你怀疑人生。关于这里我记录一个现象某个合作方接口在高峰期响应超过 10 秒我们的进件接口做了同步等待结果导致借款 APP 直接卡死在“提交中”。原因是把征信调用写成了同步阻塞没设置超时和降级机制。解决方法是征信调用全部异步化先给用户一个“审核中”的中间状态规则引擎在后台完成决策后再推送结果同时给第三方接口加 3 秒超时和本地缓存黑白名单缓存命中时根本不用出网调用。另一个合规红线第三方评分和内部评估维度不能直接拼接成复合变量输出到日志否则就是隐私泄露。所有征信相关数据只进不出截图导出要打水印。5.2 放款与代扣通道的幂等设计回调时序里的三个坑支付通道是账务系统最容易出鬼故事的地方。放款和代扣本质上都是异步流程你的系统发起请求第三方通道处理完后回调通知结果。这里最经典的坑有三个重复回调同一笔订单通知两次、乱序回调扣款成功回调先到放款回调后到、漏回调需要主动对账查询。解决方案只有一个幂等 状态机校验。def handle_payment_callback(payload): txn_id payload[transaction_id] # Redis 分布式锁防重复处理 lock_key fpay_callback_lock:{txn_id} if not redis_client.set(lock_key, 1, nxTrue, ex300): log.info(duplicated callback, skip: %s, txn_id) return trade payment_record.find_by_txn_id(txn_id) if trade.status SUCCESS: # 幂等已成功的交易直接返回 return if payload[biz_type] DISBURSE: loan loan_repo.find_by_id(trade.loan_id) if loan.status in (REPAYING, SETTLED): return loan.status REPAYING create_repayment_plan(loan) elif payload[biz_type] REPAY: apply_repayment(trade.loan_id, trade.amount_cents)这段代码的意图是演示回调处理的防御姿态先拿交易号加锁处理前检查当前业务状态已经成功的不重复处理。落库时还要记住——支付回调的金额要以支付通道返回为准而不是以本地订单金额为准因为海外通道处理小额代扣时经常有手续费拆分金额不一致时要以通道侧金额为准生成差异流水等日终对账再处理。这里我踩过的一个坑是代扣失败短信发给了用户以后用户自己手动还款成功了结果系统又在下一个批次把该期标记成逾期。原因是手动还款成功没有立即解除该期的正常委托代扣标记。解决方法是还款成功时同步取消未执行的代扣计划这个逻辑在源码里要明确找到否则就是无声的资金占用。5.3 PII 数据安全三件套脱敏、日志清理、保留与销毁海外对个人敏感信息的监管一年比一年严这不是政策问题是生存问题。贷款系统里用户手机号、证件号、银行卡号是最高频的敏感字段至少要落地三层存储加密AES 加密敏感列、展示脱敏管理后台和客服工具实时打码、日志过滤禁止把请求体原样打出来。def mask_phone(phone: str) - str: if len(phone) 7: return **** return phone[:3] **** phone[-4:] def mask_id_num(uid: str) - str: if len(uid) 8: return **** return uid[:4] ******** uid[-4:]脱敏函数的意图是让所有能在界面上看到 PII 的地方只展示打码后的结果真实值只允许在强权限的审核接口里按需解密。这里有一个我记忆深刻的教训测试环境为了方便调试直接把生产库导入测试库测试库里所有用户手机号和身份证号明文可查查询日志里也带着完整请求参数。原因是没有做数据漂白和日志脱敏的强制流程。解决方法是生产到测试的数据同步必须走脱敏脚本并且把日志网关层的 filter 加上关键字清洗规则。另外交易流水和用户数据要有明确的保留周期过期的要定时销毁不要因为“万一以后用得上”就把底层数据无限期留着留着就是风险敞口。6. 全链路演练与对账脚本验收一套贷款源码值不值得上生产最后一步不是上线是先做一轮全链路账务演练。我拿到任何一套贷款源码第一件事是拿小金额产品跑一遍“进件—放款—部分还款—全部结清”的完整流程顺便插一笔逾期订单进来看罚息是不是跟手工计算一致。这个过程里最有用的乱账查杀工具是一段平账校验 SQLSELECT account_date, SUM(CASE WHEN biz_type LOAN THEN amount_cents ELSE 0 END) AS total_disbursed, SUM(CASE WHEN biz_type REPAY THEN amount_cents ELSE 0 END) AS total_repaid, SUM(CASE WHEN biz_type WRITE_OFF THEN amount_cents ELSE 0 END) AS total_written_off FROM transaction_log GROUP BY account_date HAVING total_disbursed - total_repaid - total_written_off ! 0;这段 SQL 的意图是每天核对资金等式当日放款总额减当日还款总额与核销总额理论上应该等于当日新增的未偿本金余额不一致就说明有某笔交易没有正确落到存量和余额。我习惯再补一张按 loan_id 聚合的校验表把每个订单的本金收支算一遍和还款计划表的未还本金对平任何一笔差异都要在当天定位到具体订单。全链路演练至少要跑三种数据量级最小金额、最大金额、含服务费和逾期的复杂订单每种都要拿到手工计算确准的预期值再快照比对。这里我说一个自己的习惯验收阶段从来不看管理后台的报表页面报表都是别人写好的视角我只看三张原始表——订单表、还款计划表、交易流水表自己写 SQL 用最笨的方式核对。界面好看的源码到处都是账务扛打、又能参数化扩展产品线的贷款平台源码才是真的稀缺货。买之前先按这个办法跑一遍能省掉上线后无数个对账的深夜。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
