• 注册
  • 发动态
  • 发帖子
  • 发视频
  • 发红包
  • 暂没有数据

  • 推荐
  • 视频
  • 关注
  • 瓷器
  • 字画
  • 玉石
  • 钱币
  • 铜器
  • 木器
  • 紫砂
  • 杂项
  • [ls_fbk]
  • 查看全文
  • 查看作者
  • 宫论项目开发记录

    记录2023年项目进度周期。

  • 2
  • 402
  • 0
  • 7.38w
  • 小小乐小可鸭鸭

    请登录之后再进行评论

    登录
  • 0
    小小乐lv.2实名用户
    2024年5月25日
    1、xc_pay_config后台支付配置新增一个设置字段:income(平台扣除手续费),淘货/鉴定报告/商户订单/拍卖(C2C交易需设置平台手续费,平台自营交易则免除手续费)。设置为0则平台不收取手续费,只能为整数。单位是百分比。注:C2C:用户与用户的产生的交易支付订单。在订单进行结算的时候,会根据这里的配置来结算交易方的余额(支付金额,扣除平台抽成)等于卖家商户鉴定师获取的余额。
    2、订单支付涉及到平台交易安全,用户资金安全。出于安全考虑。xc_pay数据表额外新增两个字段:1、ip:下单完成付款的用户客户端IP地址。2、fingerprint:APP设备匿名标识、浏览器指纹参数(APP端或读取唯一设备标识码,浏览器因为获取不到标识码会通过系统扩展来生成一个标识码)。fingerprint是指纹标识,可以通过指纹版数据表来获取设备详细信息参数。这两个字段会记录用户完成付款的设备信息参数。
    3、通过add_payment_order_hook发起订单创建,完成一些列的安全检测后。进入订单创建的环节时,会将以下一下字段封装到数组:【user_id:付款用户/当前用户、seller:卖家/商户如果未传递则标记0、shop_order:商品的唯一编码信息、shop_type:支付场景和类型、pay_amount:本次订单需要支付的金额、pay_time:支付时间,当前的日期。state:标记未wait(等待付款)、ip:创建订单的IP信息、fingerprint:创建订单的设备指纹标识、title:商品的标题、close:订单付款截止时间,通过$pay_config['timeout']来计算,如果没有设置则标记为默认值30分钟】数据库的写入方式为xc_insert_sql,返回ID(主键).如果sql写入失败则返回错误【订单创建失败:数据库写入失败!】
    4、通过统一支付订单创建接口,完成数据库的写入工作后(取得了支付表的主键ID)会创建token令牌(md5('payment:' . $id)),然后封装令牌数组(包含内容:user_id、ip、ua、id、shop_order、time)参数信息,然后以token作为缓存名写入到redis数据库中。有效期为86400(24小时)。然后返回code=0、msg='支付订单已生成'、token=‘令牌字符串’到前端响应。
    5、新增订单创建成功回调通知钩子:add_payment_order_ok_hook($id) id是被创建的xc_pay数据表ID主键。当通过钩子成功写入了支付订单数据的时候,该钩子会触发。这个钩子将负责商品数据表冻结业务逻辑,比如用户创建了淘货商品待支付订单,那么淘货商品状态就需要被锁定,防止别人也能点击下单。或者直接将商品从大厅广场中移除处理。根据业务场景的不同,钩子对原商品订单的处理方式不同。这里集成一个回调钩子,来负责业务的处理。
    6、订单创建成功回调钩子会通过wpdb去查询订单支付表数据,并从中提取出【id、type、order、statte、user_id、seller】等关键字段参数,然后根据type来执行不同的业务逻辑(比如冻结锁单、比如消息通知、比如缓存清理)等等。因为每个业务都需要根据实际情况来处理事件。注:这里通过wpdb来获取数据表的原因是,订单数据涉及到交易安全,非必须情况一律采用数据库获取信息。确保数据可靠性,禁止使用缓存数据。
    7、考虑到其它业务也可以需要追踪支付订单进程,add_payment_order_hook集成现在支持动作回调钩子,在完成xc_pay数据表的创建工作后,在返回结果前会携带$result数组和data数组进行xc_do_action动态钩子注册工作。如果有第三方函数需要知道回调(订单创建成功后,进行自己的业务操作)则可以直接通过内置方法来注册函数。注:自定义注册的钩子事件不允许返回内容。
    8、在创建支付订单的时候,为了防止出现重复创建(连续点击、网络不稳定多次提交)等情况,add_payment_order_hook触发后会进行加锁处理;锁名为:add_payment_order-' . $order。有效期30秒。在执行订单创建的时候,会检索订单是否正在执行,如果正在执行则阻止用户创建,并返回错误【订单创建失败:你的操作太快了】。该锁旨在保护同一个订单出现多次并发支付的可能。注:当返回结果时(无论是成功还是失败)都会主动触发xc_unlock($redis_key)来释放锁。
    9、综合考虑,xc_pay增加一个字段:type(订单支付场景)原来的支付方案是通过shop_type来建立支付场景,并且所有的支付方案都是通过这个字段来完成。一般情况下也能满足需求。但是即个别情况会暴露出问题,shop_type和shop_order最初的设定是锁定商品信息,通过商品类型+商品编号。业务可以区分出订单是出自何处。如果将shop_type还用作支付场景,如果同一个商品存在两种支付问题,那么就会出现混乱。比如拍卖藏品费用、拍卖保证金。她们都率属于一个订单。但是存在两个支付类型。这里就会破坏shop_type字段。所以综合考虑,决定摒弃shop_type字段作为支付场景的用途,改为使用type来锁定支付场景。这个调整会改变整个支付结构。
    10、统一订单生成钩子,结构进行调整。1、新增type:支付场景变量,该变量强制要求提供。2、shop_type和shop_order可选变量,如果是固定商品,则需要传递商品类型和编号。3、redis安全锁机制调整,如果存在shop_order则使用其作为核心变量来上锁处理,避免订单出现重复执行。如果shop_order不存在则使用$_SERVER['REMOTE_ADDR']作为核心变量来上锁,避免用户重复提交订单。
    11、移除支付配置【locking】锁单保护机制,不在通过后台配置决定订单是否需要被锁保护。改为通过是否传递【shop_type、shop_order】来判断是否需要锁定,虚拟类、一次性交易类商品不需要传递这两个参数,只要不传递就代表不是固定商品。这样的判断更完善,并且有效减少了后台配置凌乱的情况。注:shop_order有两个场景会涉及sql的查询处理。1、锁单保护,只要传递了shop_order就要执行锁定保护,避免重复创建订单。2、shop_order如果存在支付成功记录,则拒绝用户继续下单。不免一个订单两次付款记录。
    12、三元运算处理data数组进行时,对于空值或不存在的会这样进行参数调整写入。1、title:如果未传递则直接写入false,后续会有严重如果不存在直接返回错误。2、type:如果未传递则直接直写入false,与type一样会有验证 不存在返回错误。3、shop_type和shop_order因为字段会写入数据表,所以如果存在空值会直接写入空字符。4、amount:支付价格,如果不存在或者不为数字(包含小数点、字符类数字)则写入false。后续会验证,如果不存在则返回错误。5、user_id:如果未传递则会通过xc_is_login函数获取当前用户,如果不存在会返回登录提示。6、seller:卖家/商户的UID,如果不存在则设置为0。
    13、通过统一支付订单生成钩子来创建xc_pay数据表记录时,用户可以根据实际需要来传递remake数组参数(data的子数组),如果没有传递该变量(通过is_array进行三元检测)则会赋值一个空数组过去。该数组在订单写入前会将当前访客的信息写入到UA、ip、fingerprint三个字段。如果支付业务需要其它自定义字段,则需要主动通过data['remake']来写入。注:remake可以理解为自定义元字段,根据实际业务需要来记录对应参数。比如收货地址、订单备注、缓存令牌等等。
    14、统一支付订单创建钩子add_payment_order_hook完成封装,新版所有的支付请求都需要提前通过这个钩子来完成订单创建。该钩子具备以下特性。【1、返回标准的数组结构,code=0代表创建成功,携带TOKEN通讯令牌。code=1是处理失败,msg是详细原因。2、安全拦截机制,根据订单类型进行上锁处理,防止出现重复支付,并发冲突的现象。3、内置wpdb语法来检测商品订单是否有过支付记录,是否处于冻结状态,避免出现二次支付情况。4、对提交过来的支付参数会做检查,如果是非法或缺失会主动拦截。5、获取支付配置,根据支付配置做对应的安全拦截,如果支付配置不存在则返回错误信息。6、符合支付场景要求则会通过xc_insert_sql来完成订单创建,完成订单创建后会生成token令牌,令牌会包含当前客户端相关信息。7、加入add_payment_order_ok_hook回调钩子,对于不同的支付场景,通过回调钩子来完成操作(比如锁单、冻结)等事件。8、通过xc_do_action来完成动态钩子关联,允许其它业务接受订单创建的消息。9、钩子执行完所有的业务后,会返回token令牌给前端进行处理】
  • 0
    小小乐lv.2实名用户
    2024年5月24日
    1、支付参数配置页新增支付场景(人脸识别费用)唯一标识:人脸识别费用。付款可用方式(1、余额支付。2、支付宝付款、3、微信付款)。登录限制(关闭,人脸识别场景作用于游客访客模式,需要找回密码,需要账户解除冻结等情况)。允许重复支付(开启,虚拟充值不需要考虑订单冻结问题)超时关闭时间(10)分钟,超过时间自动关闭。注:人脸识别接口由于成本较高,无法做到一直免费。因此需要集成支付功能。
    2、支付订单数据表新增两个字段:payment_order:商户订单号(考虑到支付单号具有唯一属性,如果用户重复付款会产生异常,不同用户发起支付或者发生改价行为,那么再次提交支付申请,会因为参数异常,被服务商接口拒绝。因此商户单号不能通过商品编号去提交付款,而是每次创建订单的时候,都生成一个唯一商户编号)close:时间日期字段,这个字段作用于系统定时计划和倒计时设计。每次生成订单的时候,会获取订单锁定有效期,超过时间内将会关闭支付,并释放订单。
    3、xc_pay数据表增加索引机制,提升支付记录查询的能力和性能。组合索引字段:shop_order、shop_type、pay_select、user_id、state。单字段索索引字段:close、payment_order、seller。所有字段都尽量采用varchar类型,确保相关支付订单查询的时候,查询性能可以做到极致。主要的的查询场景(用户支付记录、用户退款记录、平台收益记录)
    4、支付订单数据表新增字段:remake(text长文类型:数组结构存储信息)该字段设计是多个场景使用,采用数组结构来写入数据,可以确保需要的参数都可以自由扩展填充进去。目前有两个场景有需求(title:支付订单的标题信息、避免每次通过溯源方式去读取、remake:允许用户进行支付订单备注。如果需要写入商品短代码、商品图片、商品link等,都可以通过数组形式写入)
    5、支付场景配置xc_pay_config新增字段:remake(是否需要订单备注),如果是[实物订单需要发货的类型]则可以开启考虑开启备注功能,启用后付款页面会有个备注的文本输入框,用户可以在这里填写一些备注。比如发货快递指定,商品款式选择等信息。在发货的时候,会展示这个字段内容给卖家货商户。注:订单备注功能目前尚未集成到淘货或拍卖业务中,需要后续进行对接处理。该功能必要重要,需要集成。
    6、增加订单支付生成钩子:add_payment_order_hook($data),data是数组结构,必定包含的字段参数如下:type:订单付款类型(需要与后台配置对接好)、pay_amount:实际支付金额:(如果包含运费的话,需要将其写入到marke数组中)、title:支付商品标题、order:商品的编号信息、payment_order:商户订单号。这五个字段是必备的,如果业务有其它字段需要传递,则根据需要进行传递。注:order和payment_order这里需要特别注意,order一般为商品编号和商品订单号。配合type可以获取到商品信息,比如tao、bzg。如果是虚拟商品则可以随机生成。payment_order是商户支付编号,这个都是随机生成,确保订单重复支付不会出现问题。
    7、支付订单数据表新增字段:title(商品标题信息)这个字段犹豫纠结了许久要不要加,如果加会增加表的开支。最早的方案是通过type、oreder来获取关联商品信息,这个方法过于笨拙,首先查询有性能耗损,其次如果商品改名字了会有信息偏差。后面又将其写入remake数组,这个方法又感觉不够直观,需要先调用查询数组在进行获取、但是支付商品:title是必备参数,这样的处理会导致索引无效。经过对比,最终还是决定通过增加字段的方式来处理比较稳妥。
    8、统一支付订单创建钩子:add_payment_order_hook现在会返回标准的数组结构,code=0代表支付订单创建成功,code=1代表支付订单创建失败。msg是失败的详细原因。创建支付订单的时候会进行各项参数检查,对设备环境、支付场景、订单状态、用户状态都会进行细致入微的检查核验,因此被拒绝的下单原因有很多。这里都会统一返回code=1,msg附带详细错误。
    9、支付订单创建基础拦截事件如下:1、通过三元运算对传递的数组变量【title、type、order、amount】进行处理,如果不存在或者为空则直接赋值false。然后通过empty对【type、order、amount】进行参数检查,如果有值不存在则直接返回错误:订单创建失败:支付参数信息不完整。2、读取后台支付配置信息,使用xc_is_pay_config方法对支付场景进行检测,如果返回code1,则说明付配置不存在返回对应错误。3、使用empty对$pay_config['open']进行检测,如果为空则代表关闭了场景支付。返回错误提示【订单创建失败:管理员已关闭当前支付场景】。
    10、通过钩子创建支付订单,data传递数组信息新增一个强制字段:user_id(等待支付的用户),因为存在游客访客的支付模式,所以不能直接通过xc_is_login来获取用户UID 这会造成一些支付场景出现身份识别异常的情况,有效的解决方案就是手动提前传递UID。同时增加一个拦截机制,如果$pay_config['login']是开启状态(必须登录用户才能发起支付),那么会通过xc_is_login来获取当前用户UID,并重新复赋值覆盖user_id变量。最后检测user_id是否存在值,如果不存在则返回错误【订单创建失败:请登录后操作!】并附带jump:login。要求前端页面发起登录框。
    11、订单生创建成钩子增加锁单保护机制:如果提交的支付场景禁止重复支付($pay_config['repeat'])那么将会引入超全局变量$wpdb,然后创建sql查询语句,检索数据表xc_pay中是否存在(shop_order:商品单号与当前下单商品一致) 并且state状态等于wait(待支付)的订单。如果存在则获取原订单支付用户(user_id)和主键(id)两个字段。然后进一步判断。如果原订单用户和当前用户一致。则不单独创建支付订单,而是返回原订单ID参数给前端。如果当前用户不是原订单用户则返回错误【订单创建失败:该商品已被别人锁定订单】。注:主要避免用户重复下单,避免正在交易的订单被别人抢先下单。属于一种冻结保护订单。
    12、支付订单的token通讯令牌设计完成,该令牌负责前后端交互通讯 采用加密字符来核验用户设备信息。令牌有效期设定为24小时 但是如果订单出现关闭或付款成功都会触发缓存删除。这里的有效期只是一个保障,避免异常导致缓存常驻。令牌字符串【md5('payment:' . $id)】ID是支付数据表的主键ID。注:令牌作为一串加密字符串,会在订单创建成功后直接返回给前端,前端后续做交互需要通过传递这个令牌字符串。
    13、通过add_payment_order_hook创建支付订单时,会进行wpdb查询,如果【type:支付场景+order:商品编号】存在订单记录,并且state的状态为OK的情况下,则会组织用户下单 发你错误信息【订单创建失败:订单已有付款成功记录,请勿重复支付】order具有唯一属性,主要防止用户在支付页面对同一订单进行支付反复支付行为。
    14、通过add_payment_order_hook创建订单时,可以选择性通过data数组来决定是否传递seller(/收款方(卖家/鉴定师/商户/转账收款人))变量。如果是平台虚拟类充值。那么可以选择不传递。如果是用户和用户之间的交易(包含:淘货卖东西、私人转账、鉴定藏品、商户拍卖)则需要主动传递,因为这里会涉及到订单结算问题。为了防止出现报错,会通过三元运算进行处理,如果未传递则会标记为0。
  • 0
    小小乐lv.2实名用户
    2024年5月23日
    1、xc_pay_config_hook已集成微信支付配置,通过该钩子可以获取到以下参数信息。1、mch_id:微信支付服务商的ID参数。2、mch_secret_key:v3 商户秘钥(支付请求需要核验该参数信息)。3、mch_secret_cert:商户私钥pem文件信息。4、mch_public_cert_path:商户公钥证书,配合私钥完全敏感操作,比如退款行为。5、notify_url:回调通知接口。6、mp_app_id:公众号id信息,公众号支付需要改参数。7、app_id:APP的ID信息,APP支付需要用到。
    2、xc_pay_config_hook已集成微信支付配置,通过该钩子可以获取到以下参数信息。app_id:支付宝分配的应用ID参数。2、app_secret_cert:应用私钥信息(加密后的)。3、app_public_cert_path:应用公钥证书(文件)。4、alipay_public_cert_path:支付宝公钥证书。5、alipay_root_cert_path:支付宝根证书。6、return_url:同步回调地址、7、notify_url:异步回调地址。
    3、后端近期新增HOOK钩子列表。1、xc_binding_phone_hook:账户【解绑】新手机号的业务钩子。2、xc_binding_phone_ok_hook:处理手机号手动绑定成钩子函数。3、xc_rebind_phone_hook:手机号换绑处理钩子。4、xc_binding_email_hook:账户绑定邮箱请求。5、账户邮箱变更回调钩子:xc_binding_email_ok_hook。6、xc_rebind_email_hook:邮箱换绑处理钩子。7、xc_idcard_verification_hook()通过身份证姓名和号码,核验是否一致。该接口需要付费。8、xc_face_check_hook($real):人脸识别核验请求钩子,验证是否被允许进行人脸识别。9、xc_face_result_hook($face):人脸识别结果查询钩子。10、xc_face_ok_hook($id):人脸识别核验成功回调钩子。11、xc_download_hook($url, $saveDir):使用cURL下载文件并保存到指定目录。12、xc_upload_hook($id):本地文件上传到云端服务器钩子。ID是xc_upload数据表的主键,上传文件需要先按照流程保存到服务器。
    4、前段近期新增的HOOK钩子列表。1、xc_hook_binding_phone(status):绑定或解绑手机号的请求事件。2、xc_hook_binding_phone_ok(binding, type):绑定手机号成功回调钩子。3、xc_hook_rebind_phone(type):用户可以通过这个钩子来发起换绑手机号。4、xc_hook_binding_email:绑定或解绑账户邮箱号。5、xc_hook_binding_email_ok(binding, type):账户邮箱账户发生变更后触发的回调钩子。6、xc_hooke_real_personal():个人实名认证钩子。7、xc_hooke_real_personal_ok(msg):账户个人实名认证成功回调钩子。msg包括id/table_name两个字段(xc_face的表名和主键ID)。8、xc_hooke_face_sdk(certifyId):调用SDK,发起人脸识别。9、xc_hook_face_result(face_result):人脸识别处理结果核验,通过这个钩子将SDK返回结果提交到后端处理。10、xc_hook_h5_evaljs(data):网页与APP通讯钩子【底层SDK插件处理】。11、xc_hook_app_evaljs(data):APP与网页通讯钩子【底层SDK插件处理】。
    5、新增公共库目录【/global/pay】支付目录,该目录包含以下文件(支付请求文件、安全检测文件、支付回调文件、支付接口配置、支付证书、秘钥证书、公钥文件)等。涉及到新版支付请求的内容和对应文件都通存放于这个目录,短代码访问路径:[xc_link type=global]/pay/XXXX.php。需要特别注意的一点,证书秘钥的文件需要通过加密处理,防止泄露造成安全问题。
    6、新增支付目录路径短代码[xc_link type=pay]指向地址:【/wp-content/module/public/function/acocoa/global/pay/】。涉及到支付文件的调用读取都必须通过短代码形式去获取路径,这样以后如果需要对文件路径做出调整和修改时,只需要修改短代码即可完成。
    7、前端xc对象新增属性xc.pay_url指向(支付模块文件地址目录),前端如果需要调用或者访问支付文件的时,也必须通过xc.pay_url来获取短代码路径。禁止通过绝对路径来访问支付文件,后期支付接口可能会有调整,前后端的访问请求都必须通过短代码方式来处理,这样可以做到调整路径不需要修改源文件文件。注:前端xc.pay_url后端[xc_link type=pay]。
    8、新增统一支付文件:/global/pay/unified_payment.php。页面唯一标识【unified_payment】。该页面负责所有支付请求,页面会生成订单信息、支付金额、交易单号、订单生成时间等内容,并根据支付配置来获取支付菜单选项。用户可以在这个页面核对信息,并选择自己的支付方式。注:统一收银台,只要接入新版支付体系,就需要通过该页面来完成最后的支付。
    9、新增类名[unified_payment_content],锁定元素位置(宫论支付页面page-content区域),统一支付页面的(央视菜单、自定义图标、信息表单、地址选择框、支付选择)的CSS都通过该父级类名来创建和定义,避免出现类名冲突,导致全局样式出错的问题。注:支付页面所有的元素都需要通过绑定unified_payment_content类名来完成样式操作。
    10、新版宫论支付流程的规划设计如下:全面审核下单请求,确保交易合法,用户合规。生成Token令牌,保护用户信息,方便系统通信。设定支付场景过期时间,避免二次交易,提升效率。全面安全检测付款请求,防止异常情况。异步回调处理支付结果,增强系统稳定性和可靠性。使用钩子控制业务逻辑,提升流程灵活性和可维护性。
    [1]业务场景发起下单请求:用户提交下单请求,将参数信息送达后端处理。后端将严格效验下单请求,包括环境安全、订单安全、订单冻结及交互关系等。如果请求不符合条件,将直接返回对应错误信息。如果符合条件,将根据具体情况冻结或锁定订单。锁定的订单将无法被其他用户下单。然后,后端将创建支付订单记录,将订单信息录入数据表,并返回主键ID。
    [2]生成Token令牌:创建待支付订单信息后,后端将生成一个随机Token令牌,包含数据表主键ID和当前下单用户的基本资料(如设备指纹、UA、IP等)。此Token令牌将被返回给前端。注意,直接返回订单ID或数据表主键有安全风险,最好生成有效期Token以完成通信,避免信息泄露。
    [3]前端处理Token令牌:前端收到Token令牌后,将携带该令牌跳转至宫论统一支付页面。支付页面会解析Token令牌,阻止与令牌不一致或解析失败的用户下单。
    [4]展示订单信息:如果Token令牌有效,将读取并展示订单信息。同时,根据当前订单支付场景读取支付配置信息,展示支付额外参数(如收件人、备注、订单支付方式等)。付款页面将有实时支付倒计时。
    [5]倒计时设计:每个支付场景都可以设定过期时间,例如,用户下单淘货商品后,为防止二次交易,需要在付款前冻结订单。这个冻结时间一般在10分钟以内。冻结期内,用户可以进行付款操作。如果超过时间订单还未付款,系统任务将完成订单解锁。如果一直不解锁,商品将无法被其他人下单或查看。倒计时可以视为锁定和释放订单的过程。用户可提供主动取消订单的选项,完成释放请求。同时,因系统超时而释放的订单,会将次数记录在用户每日行为缓存记录中,如有10次或N次锁定订单而不付款,视为恶意行为,将限制用户一段时间内的支付或下单能力。
    [6]用户选择付款方式并发起付款请求:后端首先进行安全效验,检测环境、用户、订单之间是否异常。这是支付流程中最全面、最细致的检测。如果存在异常,将终止付款请求,并返回对应错误。
    [7]获取支付配置参数:如果支付得到许可,将根据支付类型(支付宝、微信、银联)+支付渠道(APP、小程序、H5)通过SDK获取支付配置参数。然后,调用统一支付钩子获取订单数据包或其他相关数据。如果获取失败或接口异常,将返回对应错误信息。
    [8]完成订单支付信息交互:H5将返回支付链接,APP和小程序公众号将返回支付凭证。此时,将根据业务场景的不同,进行SDK发起、页面跳转等行为,最终目的是打开链接或调起支付请求。
    [9]支付回调处理:支付结果有两种通知方式。APP端可通过同步回调实时获取支付结果,直接根据返回参数判断支付情况。H5和微信公众号通过异步回调接收支付结果,因为是通过跳转链接完成支付,此场景只能通过异步回调接收支付结果。
    [10]、异步回调方案:订单状态回调将统一采用异步完成,禁止APP端使用同步回调结果执行后端订单回调动作,以避免可能的伪造信息,造成未付款订单被标记为已付款。异步的优点在于接口加密、参数传递加密、跨端支持。后续将封装一个回调接口钩子,专门处理订单支付成功后的业务逻辑。
    [11]前端采用websocket处理订单支付成功后的页面交互动作:设计一个支付订单成功的回调页面,当用户收到websocket(订单支付成功)的数据包,将自动跳转至此页面,告知用户付款成功。
    注:全程采用钩子执行业务逻辑,整个支付流程每个环节都将采用前后端钩子来执业务,确保每个环节都可以被接管和修改。同时支付过程中会集成日志报警、账单计数、用户行为、redis等功能模块,确保业务的健壮稳定性。
  • 查看全文
  • 查看作者
  • 文章测试

    江西·萍乡
  • 4
  • 54
  • 0
  • 6.35w
  • 咸鱼梦想小可鸭鸭小小乐学藏官方

    请登录之后再进行评论

    登录
  • 0
    欣然lv.1
    最低多少钱?最低多少钱?
  • 0
    咸鱼梦想lv.2实名用户
    测试看看最低多少钱?
  • 0
    咸鱼梦想lv.2实名用户
    内容测试出
  • 查看全文
  • 查看作者
  • 鉴定师入驻协议

    欢迎使用宫论APP鉴定师入驻申请功能,本协议主要阐述您申请成为相关领域鉴定师的相关的权利和义务,请您务必仔细阅读。一、概述 1、本协议内容包括协议正文及所有宫论已经发布或将来可能发布的关于鉴定师入驻。所有规则为本协议不可分割的一部分,与协议正文具有同...
  • 学藏官方 学藏官方
  • 3
  • 50
  • 673
  • 官网公告
  • 2023-03-20 09:21 电脑端
  • 查看全文
  • 查看作者
  • 宫论藏品寄售协议

    欢迎使用宫论APP藏品寄售申请功能,本协议主要阐述您作为藏品持宝人相关的权利和义务,请您务必仔细阅读。一、概述 1、本协议内容包括协议正文及所有宫论已经发布或将来可能发布的关于藏品回收的规则。所有规则为本协议不可分割的一部分,与协议正文具有同等法律效...
  • 学藏官方 学藏官方
  • 1
  • 1
  • 908
  • 官网公告
  • 2023-03-17 08:58 电脑端
  • 查看全文
  • 查看作者
  • 藏品回收申请协议

    欢迎使用宫论APP藏品回收功能,本协议主要阐述您作为藏品持宝人相关的权利和义务,请您务必仔细阅读。一、概述 1、本协议内容包括协议正文及所有宫论已经发布或将来可能发布的关于藏品回收的规则。所有规则为本协议不可分割的一部分,与协议正文具有同等法律效力。...
  • 学藏官方 学藏官方
  • 1
  • 1
  • 800
  • 官网公告
  • 2023-03-13 09:29 电脑端
  • 查看全文
  • 查看作者
  • 宫论藏品鉴定协议

    欢迎使用宫论APP鉴赏功能,本协议主要阐述您作为藏品持宝人相关的权利和义务,请您务必仔细阅读。一、概述 1、本协议内容包括协议正文及所有宫论已经发布或将来可能发布的各类规则。所有规则为本协议不可分割的一部分,与协议正文具有同等法律效力。 2...
  • 学藏官方 学藏官方
  • 1
  • 0
  • 778
  • 官网公告
  • 2023-03-11 15:17 电脑端
  • 查看全文
  • 查看作者
  • 淘货发布协议

    淘货发布协议在宫论APP为了能够约束好每个卖家发布商品,也制定了统一的商品发布规范,如果各位也想要开淘宝店铺,那就需要好好去了解一下宫论APP商品的发布规范。第一章 概述第一条【适用范围】适用于在宫论APP发布商品的卖家。第二条【效力级别】本规范已有规定的,适...
  • 学藏官方 学藏官方
  • 2
  • 0
  • 784
  • 官网公告
  • 2023-03-09 15:33 电脑端
  • 查看全文
  • 查看作者
  • 宫论提现协议

    宫论提现协议 《宫论钱包提现协议》(以下简称“本协议”)适用于所有在宫论平台进行提现的用户(以下或称“您”)。本协议被视为《宫论用户服务条款》的补充协议,是其不可分割的组成部分,与其构成统一整体。本协议与《宫论用户服务条款》内容存在冲突的,以本协议为...
  • 学藏官方 学藏官方
  • 2
  • 0
  • 841
  • 官网公告
  • 2023-03-09 11:44 电脑端
  • 查看全文
  • 查看作者
  • 消费者保障服务协议

    本协议由您与济南谋佐科技有限公司共同缔结,本协议具有合同效力。本协议中协议双方合称协议方,济南谋佐科技公司在本协议中亦称为“宫论”。一、协议内容及生效1、本协议内容包括协议正文及所有宫论已经发布或后续发布的相关的规则与协议。前述规则与协议为本协议不可分割的组成...
  • 学藏官方 学藏官方
  • 2
  • 0
  • 703
  • 官网公告
  • 2023-02-25 20:27 电脑端
  • 查看全文
  • 查看作者
  • 店铺保证金协议

    一、什么是店铺保证金?店铺保证金是如果涉及理赔、违规处罚等情况时,可利用店铺保证金进行支付;如没有前述情况,店铺保证金可全额退回的一种机制。二、为什么要缴纳店铺保证金?(1)重点强调-店铺无违规情况认证有效期内且缴纳店铺保证金后下个整点,可搜索到店铺,若未缴纳...
  • 学藏官方 学藏官方
  • 1
  • 0
  • 763
  • 官网公告
  • 2023-02-25 20:20 电脑端
  • 查看全文
  • 查看作者
  • 宫论特殊类目经营资质

    尊敬的宫论商家:为了保障宫论类目健康、提升交易体验、维护商家及买家利益,现对于以下类目入驻认证需提供对应资质:类目店铺类型需要资质陨石骨牙-骨石企业/个人①与平台店铺认证主体信息一致的水野生保护动物经营利用许可证及副本(如许可证上未列举所有可经营物种明细的需额...
  • 学藏官方 学藏官方
  • 1
  • 0
  • 644
  • 官网公告
  • 2023-02-25 20:16 电脑端
  • 单栏布局 列表样式:矩状 侧栏位置: