程序员带你秒改支付宝余额 变身富翁不是梦 仅做朋友圈分享_腾讯视频
三倍流畅播放
1080P蓝光画质
新剧提前看
1080P蓝光画质
纯净式无框播放器
三倍流畅播放
扫一扫 手机继续看
下载需先安装客户端
{clientText}
客户端特权:
3倍流畅播放
当前播放至 {time}
扫一扫 手机继续看
程序员交给你如何修改支付宝网页端余额的技巧，仅仅当作朋友圈分享装逼之用。其实就是使用浏览器的开发人员工具进行修改网页前端代码。并没有任何技术含量。同时很多微商为了显示自己的流水量，也通过这种方式进行修改。
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要
副标题要不要【CTO俱乐部走进支付宝】探索支付宝背后的那些技术
发表于 10:24|
摘要：3月27日下午2点，CTO俱乐部“走进支付宝”活动正式开始，话题围绕阿里金融云架构体系技术特征、支付宝公众平台开放等问题。
即刻申请加入，报名参与更多精彩活动。3月27日下午，“CTO俱乐部走进支付宝”活动在杭州举行，此次活动邀请到支付宝首席架构师程立、小微金服安全产品技术部负责人曹恺、、小微金服无线技术部负责人李杨东、阿里巴巴金融云负责人潘立维，与CTO俱乐部会员一起分享有关互联网金融时代，该如何满足用户便利性和安全性双重体验要求的一些理念和实践？阿里金融云服务中，金融云服务的架构体系、技术特征以及代表性客户案例，支付宝公众服务平台的开放情况等话题。活动吸引了数十家来自不同企业的技术管理者，由CSDN&《程序员》总编刘江主持，他认为作为公司的主要技术负责人，要意识到整个产业近几年的变化，及时考虑公司转型。他说：“这几年尤其是从iPhone出来以后，其实整个IT产业包括对其他行业的影响已经天翻地覆了，技术经理或技术部的人在企业里面责任也是越来越大。从技术圈里出来的东西，可能会对你公司的整个方向都是有巨大的影响的。如果只是把原来公司的业务做的很好，这种舒服的日子很可能会被干掉，诺基亚、摩托摩拉等就是例子。”“CTO俱乐部今年想更多地做一些活动，给大家更多的启发、思考，也促进大家在技术层面、业务层面一些合作。”刘江介绍说。活动现场首先由支付宝首席架构师程立（鲁肃）致欢迎词，并向大家支付宝现在的整个情况。阿里的技术文化氛围支付宝首席架构师 程立（鲁肃）程立首先谈到的是阿里的技术文化：第一，有技术的理想。最大的梦想是什么？是每一个技术人员在阿里、在支付宝平台上面，可以做出他最大的技术成就。“我们有这么好的机会和平台，我们有责任也有机会来做出不一样的东西。”程立补充道。第二，阿里的技术人员是特别务实的。很少听到阿里人到外面夸夸其谈，要讲的都是一些很务实的东西。程立举例说：“比如说双十一，双十一最难的挑战不是我们怎么去建立一个亿级交易的平台，挑战在于这一个点怎么样保证成千上万的细节都是正确的，因为一年只有这次机会，没有任何机会能够让我们的系统做这次考验。没有办法做非常完全的设施，那这个时候其实我们会花大量的经历去检查每一个细节。”第三，非常自由、宽松的范围。“阿里的话其实所有的人最讨厌的两个字就是官僚，以我自己为例，我是支付宝的首席架构师，那我的职位是给了我很多事情我做最终决策的权力的，但是从我到首席架构师到目前为止这么多年，我从来没有用过一次的权威去作任何一个技术决策，所有的决策都是我们所有人在一起参与、商量，用大家认为最好的方式去做。”程立说。“你敢付，我敢赔”口号背后的技术支撑提到支付宝的风控，最响亮的无非是那句“你敢付，我敢赔”，小微金服安全产品技术部负责人曹恺向大家介绍了“敢付敢赔”口号背后都做了哪些技术探索。曹恺的分享分为三部分：第一，支付宝安全技术体系的理念，就是基于什么样的技术理念、或者是技术上的策略去做安全的；第二，介绍一下从2005年起支付宝有了风控体系以来，整个安全的技术体系是怎么发展的；第三，介绍主要在安全风控体系当中遇到的挑战，如何应对的以及一些关键技术点是怎么去解决的。小微金服安全产品技术部负责人 曹恺曹恺介绍说，支付宝作为一种互联网金融，安全理念更是端+云的两种方式协同去做风险控制。“首先我们更强调体验，互联网体验为王，用户第一，我们更多是看用户在这个过程当中开户开多少户，丢一户我们的流失率成功率就下降多少个点，那这个体验是很重要的，我要让用户非常方便地去使用。”曹恺说。此外相比传统金融，互联网金融的认证门槛相对会低一下，但是不代表不严格。“我们更多的是严格是通过其他方式去实现的。还有就是我们的介质会更弱一些，不会强调你到某个网点去办一张卡，或者拿一个U盾这样的物理介质。”曹恺补充说。另外还有一点是非面对面交易，网上金融是推动电子的方式去完成的。然后准入是低门槛的，但是支付宝的风控体系是层次化的。实时分析为主，更多分析是建立在用户行为分析、监督上去决定他安全不安全，决定怎么对他进行保护。总体上是云+端的协同方式，这是传统金融跟支付宝在风险控制理念上的差异。关于攻防体系，曹恺介绍说，对于一些暴力攻击、扫号，可以通过攻防体系去做一些隔离和拦截。然后监控谁在攻击？以什么样的频次攻击？攻击什么？实际上都会通过实时的监控体系发现，一旦发现有恶化的情况，会紧急的采取措施。怎么避免研发环节当中引入漏洞？“我们有一套比较成熟的安全研发开发框架。首先我们用统一的框架，框架本身是经过我们安全工程师去做过非常好的认证的，同时在研发过程当中我们对这些问题也有些规范。一旦发现风险我们在运营环节当中，你怎么去做应急响应，漏洞出现已经怎么样去限制他的扩散。”曹恺说。曹恺分享了4代支付宝安全技术架构的发展。年，1.0架构：功能简单，规则过滤，烟囱型功能模块。年，2.0架构：提供多业务支持，识别、决策和管控独立，服务化。年，3.0架构：风控体系平台，标准化快速接入，模型+规则的支持。2013年至今，4.0架构：数据云，实时智能的运营闭环，多维立体识别和管控。支付宝安全技术面对的挑战表现在四个方面：1. 容量：十亿交易量级、更多数据种类与数据量；2. 快速灵活：快速接入、快速发现、灵活部署、灵活调整；3. 性能：毫秒级的识别响应、实时数据计算；4. 智能精准：数据精准、立体识别与布控、智能分析与决策。阿里云的金融服务紧接着，阿里巴巴金融云负责人潘立维带来题为“阿里金融云助力互联网创新”的分享，他介绍了云计算以及阿里云计算为整个金融行业推出的服务。阿里巴巴金融云负责人 潘立维“去年，我们真正的云计算平台算是进行商业化了，我们在不断地跟客户磨合的过程当中，发现我们云计算越来越清晰、我们的品牌越来越完善。所以到去年真正的阿里的云计算算是真正建立了。”潘立维说。首先潘立维介绍了阿里金融云的来历和背景，紧接着他谈到金融云能给金融行业带来什么？甚至说云计算给各式各样或者IT行业带来什么？潘立维总结了三点：传统的金融行业一次彻底拥抱互联网金融的机会；金融云可以为金融行业在做业务创新上可以给他一个最小的成本，包括一个非常大的机会成本；云计算本身的价值，成本是低价格、高价值。如果没有客户，那么产品市场认知度是不够的。“我们的长处是我们经历过市场的验证，在我们这个平台上有超过10万家的中小企业，在使用我们的云计算服务，我们所有产品的引进，产品功能的完善是靠我们这些客户跟我们一起互动才把我们产品不断打造成现在这个样子的。”潘立维介绍说。真正的服务包括云服务和附带金融行业；第二类是存储和数据库，包括结构化数据库等等。第三个就是大众平台计算。潘立维介绍说全国药品监控系统就是在OTS上实现的。“全国的药品监控系统现在是国内唯一的一家第三方公众平台，他把全国4000多家药厂，十几万家零售渠道、42万家医院和96万家的零售药店，所有药品的全过程的追踪，每个药品的码都是存在这个上面的。”潘立维介绍道。提问：我主要做的是企业金融，我想了解一下就现在这个云平台，除了技术支撑以外，阿里云还能提供和支付宝这些一样包括业务场景方面的事情吗？&潘立维：我们现在正在跟支付宝做一些业务上面的整合。就是把支付宝端的业务以及理财产品的业务，还有后面持续在做的金融创新的业务，都集成到平台里面来。以后我们金融云是聚宝盆业务的改革。就是我们这些比较成熟的金融行业、企业在做金融创新的时候，来享受支付宝端给他带来的业务抓手。来享受云计算给他带来的一些技术平台。前哨阵地：支付宝钱包小微金服无线技术部负责人李杨东负责支付宝移动下面的研发团队。他带来的分享主题是支付宝的移动研发体系。“移动互联网大浪潮的到来，我们现在每一天登陆支付宝的用户数达到了千万级。”李杨东说。由于业务快速发展，带来了技术面的很多挑战。“回过头看看支付宝钱包的发展，2009年开始做，也没有说要变成一个便民生活平台，也没有什么架构、大的理念，基本上2009年~2012年基本上是处于这样的一个状态。2012年末那时候整个团队开发只有20多个人，然后到2013年的时候我们从20多个变成了400多个。” 李杨东补充道。小微金服无线技术部负责人 李杨东通过一年的“夺命狂奔”，李杨东说现在支付宝钱包已经变成了支付宝内部的一个很重要的前哨阵地，所有的业务未来有的可能发布有的可能不再发布，有些东西都会在理财钱包里面进行展示，而这个验证了我们很重要的一个业务的平台。已经从单纯的把功能做上去，变成了一个平台。接下来一步可能要全面的走向开放，把他变成一个生态圈。业务的迅速发展，给李杨东的团队也带来了很大挑战：比如原来支付宝是说做线上的电子商务，现在的发展是会和很多商户有面对面的收款，面对面引发的问题就是说收了你一笔款，然后要通知到收收款方，说这个款已经收到了。也就是说做信息流不能满足线下的严谨的场景。此外，最大的挑战就是网络场景在发生深刻的变化。“原来我们基本上不会去考虑网络问题，但是今天在移动互联网的时候，因为网络的不稳定引发了一系列的问题。还有一个问题就是说因为线上场景不一样，用户是24小时在线的。这是一个非常可怕的概念。原来的PC的时候其实人和机器是脱离的，但是在移动互联网人跟着网络，你是他的一部分。用户累，我们也累。”李杨东说。活动时间：3月27日（周四）下午2点至6点以下为图文直播报道。（为了方便大家看到最新的进展，下文将采取倒叙方式。）18:00 &现场嘉宾分享环节结束后，俱乐部会员一起参观了支付宝，进行自由交流，并一起留影。至此，CTO俱乐部走进支付宝活动完满结束。17:10 &遇到这些问题怎么办？李杨东给出的答案是“从流程上，进行大规模集中产品研发，大团队协调作战，高强度集中发版，一次把事情做对；从工具上，请平台、小产品，小团队灵活组织，动态产品发布，持续反馈打磨精品。”17:00 &“怎么开发这么久？”、“就要封板了，Bug还没修复完，怎么办？”、“客户端合并、服务端发布...赶各种时间点”、“编译一下，我都睡着了...”、“这么多协调、信息同步工作，都OK了么？”李杨东说这些问题都是支付宝钱包研发遇到的挑战，该怎么办呢？16:50 第三位分享嘉宾是小微金服无线技术部负责人李杨东，他介绍说，支付宝钱包是目前倾全力在做的一个超级App，团队从2012年的20多人激增到400多人，应用本身也超过百万代码，功能相当于100个应用，跻身亿级App俱乐部，并向平台转化。16:30 &潘立维：一直以来，金融业对灾备建设都是又爱又恨，爱的是在“数据安全”上多买了一份保险，恨的是这份保单成本太昂贵 ，还很容易掉链子，难以兑现，所以基本上大多数银行基于成本的考虑，只对核心的业务进行了灾备，外围业务只能被迫接受中断。16:00 &阿里巴巴金融云负责人潘立维说，阿里云为金融用户提供的行业云计算服务，不仅为金融客户提供安全稳定的IT资源及互联网运维服务，还提供了支付宝的标准接口和沙箱环境，帮助金融客户从容面对互联网金融带来的庞大业务量和随之而来对IT技术架构的挑战。15:50 &第二位嘉宾小微金服无线技术部负责人李杨东临时有事情，和第三位演讲嘉宾阿里巴巴金融云负责人潘立维演讲顺序进行了对换。15:40 & 提问：我是一家做金融行业的。支付宝是如何平衡对数据进行加密的同时，又保证查询性能的？曹恺：安全是第一要素，这是支付宝业务的要求。在做检索时，是否需要将加密数据还原取决于场景，有的加密采用的是单向，可以做一些优化算法去做加速；同时，可以把与业务相关的大的问题分拆，甚至会把业务做一些调整，让业务跟性能结合。此外，还会对基础设施进行升级。&15:20 & 曹恺介绍说，支付宝安全技术面对的挑战表现在四个方面：1. 容量：十亿交易量级、更多数据种类与数据量；2. 快速灵活：快速接入、快速发现、灵活部署、灵活调整；3. 性能：毫秒级的识别响应、实时数据计算；4. 智能精准：数据精准、立体识别与布控、智能分析与决策。15:00 &曹恺分享了4代支付宝安全技术架构的发展。年，1.0架构：功能简单，规则过滤，烟囱型功能模块。年，2.0架构：提供多业务支持，识别、决策和管控独立，服务化。年，3.0架构：风控体系平台，标准化快速接入，模型+规则的支持。2013年至今，4.0架构：数据云，实时智能的运营闭环，多维立体识别和管控。14:45 &小微金服安全产品技术部负责人曹恺介绍说，不同安全策略带来不同安全技术体系。传统金融偏重入口控制和身份认证的风险管控，所以认证门槛高、强调物理介质、面对面交易、高准入+日常管理、端控制。而支付宝采用的是身份识别和风险行为监控并重的风险管控，强调体验且认证门槛低、弱化介质、非面对面交易、低准入+层次化+实时分析+多层次管控、云+端协同控制。14:20 &支付宝首席架构师程立在致辞中分享了阿里巴巴的技术文化，包括三个方面：第一，阿里最大的梦想是为技术人员提供一个成就个人最大技术发展的平台；第二，阿里的技术人员特别务实，比如为双十一这种实际问题做的技术方面的努力；第三，自由、宽松的工作氛围，程立本人从未动用过一次首席架构师的权威去做技术决定，而是和大家一起来分析，鼓励年轻人的想法。14:15 &刘江：对公司来说，你的任务不仅是做项目，可能还有很多责任，因为我们现在处在一个技术大变革的时代。很多方面已经天翻地覆了，而如果公司的主要技术负责人没有意识到这个问题，进而并未及时地去影响公司的话，这是一件非常可怕的事情。CTO俱乐部就是要给大家提供这样一个交流的机会，紧紧抓住技术大变革的机会。&14:00 &CSDN暨《程序员》总编刘江开场致辞，CTO俱乐部今年将为更多CTO们提供更多思考、启发，以及促进业务层面合作的机会。在调查CTO俱乐部活动有多少人从外地过来参加的时候，目测有一半的人举手了。13:50 &离活动开始还有10分钟，然已经来了大半了！13:45 &签到的人越来越多了，工作人员表示压力很大。13:30& 活动即将开始，“CTO俱乐部走进支付宝”会议现场、签到台已经布置好。日& 程13:30-14:00& & 来宾签到14:00-14:10 & &主持人CSDN暨《程序员》总编刘江& 开场14:10-14:20 & & 支付宝首席架构师程立& 致欢迎词14:20-15:10&& &主题分享1：支付宝安全技术体系实践& & & & & & & & & & & &嘉宾：曹恺& 小微金服安全产品技术部负责人15:10-16:00&& &主题分享2：支付宝钱包移动研发体系& & & & & & & & & & & &嘉宾：李杨东& 小微金服无线技术部负责人16:00-16:50&& &主题分享3：阿里金融云助力互联网创新& & & & & & & & & & & &嘉宾：潘立维& 阿里巴巴金融云负责人16:50-17:30 & & Q&A环节17:30-18:00 & & &参观支付宝、自由交流18:00 & & & & & & & & 活动结束&CTO俱乐部是目前国内最有影响力、规模最大的技术管理者分享与交流平台，由全球最大中文IT社区CSDN创办。CTO俱乐部实行会员免费申请、实名认证的加入机制。自2009年创办以来，已有注册会员10000余名，覆盖国内数千家IT公司和各行业企业研发部门的CTO、技术副总裁、首席架构师、技术总监、工程总监等高级技术管理者。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章code monkey
支付宝接口接入方法
步骤十分详细
原文在支付宝的论坛，最近在做支付宝支付接口接入，虽然不是用主流的java/php/c#,用的是golang，但原理还是相通。原文连接：
大家想必都有这种困惑——拿到支付宝的接口代码后，尽管里面的程序有注释，接口代码包中也附有开发说明，但还是不知道该如何入手。这不难想象是什么原因，因为自己并不了解这个接口的工作原理是什么？
那么这篇文章就是要向大家全面展示关于支付宝接口的所有东西，以便大家能快速上手把接口接入自己的项目中，也能帮助那些已经对支付宝接口有所了解的程序开发者们更了解支付宝的一些通用规则、特殊用途等。
正题开始——
一般由两部分组成，接入部分与通知返回部分。接入部分即为传递参数等信息组合成超级链接，并用该链接来进行跳转。通知返回部分则是支付宝服务器对该笔订单处理完毕后，通知与返回该笔订单的详细信息到商户服务器，商户服务器接收到后，并对其进行数据处理。
以实物标准双接口ASP代码中的程序为例。
接入部分的页面文件包含：配置页alipay_Config.asp、方法详细页alipay/Alipay_Payto.asp、程序入口页index.asp以及MD5加密方法类页alipayto/Alipay_md5.asp。
通知返回部分的页面文件包含：方法详细页alipay/Alipay_Payto.asp、MD5加密方法类页alipayto/Alipay_md5.asp、支付完成后（支付宝处理完毕后）自动跳转回的自定义页面return_Alipay_Notify.asp、两方服务器间相互交互（肉眼无法见到的）通知页Alipay_Notify.asp。
这里大家可以一目了然，MD5加密方法类与方法详细页不论是哪部分都有被调用，因此这两个文件可视为核心代码部分，若想理解接口的工作原理则要从该部分入手。
以实物标准双接口的ASP.NET C#语言代码程序为例：
接入部分的页面文件包含：无需更改的ALIPAY的类文件App_Code/AliPay.cs及入口页面文件Default.aspx
通知返回部分的页面文件包含：两方服务器间相互交互（肉眼无法见到的）通知页Alipay_Notify.aspx、支付完成后（支付宝处理完毕后）自动跳转回的自定义页面Alipay_Return.aspx、无需更改的ALIPAY的类文件App_Code/AliPay.cs
这个架构是否更容易理解了？没错，核心部分的运算过程就在AliPay.cs这个文件中。
大家对结构部分已经有所了解，那么我们就开始分析具体的这个接口是如何运作的。
接入部分原理
第一步——选定参数信息：
结合技术文档以及接口代码DEMO，选定传递给支付宝服务器的参数，以实物标准双接口为例。如必传项service、partner、seller_email、sign、sign_type、out_trade_no、price、subject、quantity、payment_type以及最少一组的物流信息参数三个logistics_type、logistics_fee、logistics_payment等，选填项body、discount、show_url等。
以ASP.NET C#语言代码程序为例：
[plain] view plaincopy
string service = "trade_create_by_buyer";
string seller_email = "";
string sign_type = "MD5";
string key = "********************************";
string partner = "2088************";
string _input_charset = "utf-8";
string show_url = "http://www.alipay.com/";
string out_trade_no = TxtOrderno.Text.Trim();
string subject = TxtSubject.Text.Trim();
string body = TxtBody.Text.Trim();
string price = TxtPrice.Text.Trim();
string quantity = TxtQua.Text.Trim();
string logistics_type = "POST";
string logistics_fee = TxtPost.Text.Trim();
string logistics_payment = "BUYER_PAY";
string notify_url = "http://www.xxx.com/swnet05utf8/Alipay_Notify.aspx";
string return_url = "http://www.xxx.com/swnet05utf8/Alipay_Return.aspx";
第二步——排序：
把这些参数的变量名（即技术文档里给出的变量名，以这种方式组合：service=”trade_create_by_buyer”作为一串字符串）按从a到z的顺序依次排序。以ASP.NET C#语言代码程序为例，该功能在ALIPAY.CS类中；以ASP代码中的程序为例，该功能在alipayto/Alipay_Payto.asp文件中。
第三步——加密：
目前一般的加密方式是MD5，不论是哪种加密方式，要加密的信息是要传给支付宝的信息，且存在于技术文档中，而非自定义的变量名。对以上排序好的所有参数（不包括网关参数即：string gateway = “?”）以循环的方式，用‘&’字符拼接成一长串字符串（这里需要注意，所有的参数都是&字符来拼接的，拼接后直接再拼接安全校验码Key,在程序中大家可看到，这个key是直接加到该字符串后面而没有用&字符 ），之后进行加密。得出的加密字符串集存储于sign这个参数中。
第四步——拼接字符串成URL链接
我们已经拿到了各个参数、参数所属的值以及加密得出的加密字符串，那么手上现在的所有参数信息的格式，应当都是一组一组的service=”trade_create_by_buyer”这种格式的字符串，拼接的话，则依靠循环的方式遍历所有的这种字符串，因为这次的拼接是要成URL链接，所以之前排除在外的网关gaetway和加密类型参数sign_type也都会被拼接进来，那么，连接的字符则用大家所熟知的字符’&’，就这样得出一个完整的URL链接地址，如：
[html] view plaincopy
https://www.alipay.com/cooperate/gateway.do?seller_email=test%40126.com&discount=0&logistics_fee=0.01?ify_url=http%3A%2F%2Flocalhost%3A8088%2Fjsp_shi_gbk%2Falipay_notify.jsp&payment_type=1&service=trade_create_by_buyer&partner=6782&_input_charset=utf-8&logistics_type=EMS&price=0.01&out_trade_no=30&subject=AAA30&logistics_payment=SELLER_PAY&quantity=1&body=%E6%94%AF%E4%BB%98%E5%AE%9D%E6%B5%8B%E8%AF%95&return_url=http%3A%2F%2Flocalhost%3A8088%2Fjsp_shi_gbk%2Falipay_return.jsp&sign=a7ffc1c8ba85df972bb472adc3d199ba&sign_type=MD5
该链接来自支付宝官方的技术文档“标准实物双接口技术文档”
第五步——自动跳转
第四步中已经运算得出的URL链接字符串，我们则要让其活起来，那么活起来的方式就是——用程序调用它，也就是所谓的页面自动跳转。这样就能跳到支付宝的官方收银台页面。
可以说，现在已经成功的把支付宝接口融合进了大家自己的网站中，且能够使用支付宝来进行付款了。
通知返回部分原理
通知返回是两个页面，即传递给支付宝时的notify_url参数所对应的页面文件（asp.net的是Alipay_Notify.aspx、asp的是Alipay_Notify.asp）称之为通知页，传递给支付宝时的return_url参数所对应的页面文件（asp.net的是Alipay_Return.aspx、asp的是return_Alipay_Notify.asp）称之为返回页。
通知返回原理
第一步——验证是否是支付宝服务器发来的请求：
以asp程序代码为例：
[plain] view plaincopy
alipayNotifyURL = "http://notify.alipay.com/trade/notify_query.do?"
alipayNotifyURL = alipayNotifyURL &"partner=" & partner & "?ify_id=" & request("notify_id")
Set Retrieval = Server.CreateObject("Msxml2.ServerXMLHTTP.3.0")
Retrieval.setOption 2, 13056
Retrieval.open "GET", alipayNotifyURL, False, "", ""
Retrieval.send()
ResponseTxt = Retrieval.ResponseText
Set Retrieval = Nothing
得到的便是ResponseTxt的值，这是下面的步骤要用到的。
以asp.net C#程序代码为例：
[csharp] view plaincopy
//获取远程服务器ATN结果，验证是否是支付宝服务器发来的请求
public String Get_Http(String a_strUrl, int timeout)
string strR
HttpWebRequest myReq = (HttpWebRequest)HttpWebRequest.Create(a_strUrl);
myReq.Timeout =
HttpWebResponse HttpWResp = (HttpWebResponse)myReq.GetResponse();
Stream myStream = HttpWResp.GetResponseStream();
StreamReader sr = new StreamReader(myStream, Encoding.Default);
StringBuilder strBuilder = new StringBuilder();
while (-1 != sr.Peek())
strBuilder.Append(sr.ReadLine());
strResult = strBuilder.ToString();
catch (Exception exp)
strResult = "错误：" + exp.M
return strR
调用部分：
[csharp] view plaincopy
string alipayNotifyURL = "https://www.alipay.com/cooperate/gateway.do?service=notify_verify";
string partner = "2088************";
alipayNotifyURL = alipayNotifyURL + "&partner=" + partner + "?ify_id=" + Request.Form["notify_id"];
//获取支付宝ATN返回结果，true是正确的订单信息，false 是无效的
string responseTxt = Get_Http(alipayNotifyURL, 120000);
得到的便是ResponseTxt的值，这是下面的步骤要用到的。
第二步——排序：
该部分的排序的原理与“接入部分”的原理“排序步骤”一样，值得注意的是 ，这里的参数是支付宝通知返回时，传回来的订单信息的各种参数以及值。
第三步——加密：
该部分的加密原理与“接入部分”的原理“加密步骤”一样，依然值得注意的部分是加密的参数信息，这些参数信息是来源于上面一步骤排序好后的参数拼接起来的字符串来加密的。
第四步——判断：
上面我们有得到加密的结果（命名为mysign吧）、检验是否是支付宝发来的消息的正确性ResponseTxt、以及通过POST或GET的方式得到的sign参数的值，那么这个判断的含义便是通知返回里最重要的部分了，因为它是来检验下面的程序是否执行我们的数据处理的。如何判断呢？各语言程序代码中，都是把加密得出的结果mysign与从支付宝那或得到的sign的值进行比较，并且还要让reponseTxt这个的值要等于true，这样才达到验证成功。值得注意的是 ，大家都有遇到过这种事，支付部分即接入部分的确是做好了，但为什么无法与支付宝的交易信息同步，出现的问题就在这个判断上没有成功，下面的第五部分则会详细说明。
第五步——自身网站的数据处理
终于判断成功了，程序已经执行到了这里。各语言程序代码的这块地方的注释都写着“更新自己数据库的订单语句”或是“这里可以指定你需要显示的内容”。如字面上的意思，这块地方就是要我们大家来对这笔交易信息进行数据处理，即编写程序。这个说法大概专业了点，简单易懂的讲法便是，支付宝的交易成功的信息和其他的一切交易状态，自己的网站也能够对这笔订单同步起来，即支付宝里这笔订单的交易状态是“买家已付款等待卖家发货”，那么自己网站里显示的这笔状态也因如此，那么就应当在这里面写下诸如：
[csharp] view plaincopy
if (Request.Form["trade_status"] == "WAIT_SELLER_SEND_GOODS")//
判断支付状态_买家付款成功,等待卖家发货（文档中有枚举表可以参考）
//更新自己数据库的订单语句，请自己填写一下
string strOrderNO = Request.Form["out_trade_no"];//订单号
string strPrice = Request.Form["price"];//金额
string sql = "update order_table set order_status = ‘买家已付款，等待卖家发货’ where order_no = " + strOrderNO;
Update(sql);
等数据库处理代码。
存在的区别
大家仔细阅读代码不难发现，在通知页中程序运行时，获取参数的方法是用POST方式，而返回页中程序运行时，获取参数的方法是用GET方式。由此可知一些基本的信息——返回页传递回来的参数信息是储存在URL链接里的，而通知页的参数信息是不在URL链接里，也能从中推断出二者在功能上的差异。
大家可看到通知页面比返回页中多一个环节，那就是Response.Write(“success”);
作用上不同的详细说明，大家可以看下面的第四部分。
首先大家有个疑问，技术文档中的输入参数列表中给出了诸多参数，而手上拿到的代码里只写了一部分参数来进行传递信息，这究竟是为什么？那么我们先带着这个疑问往下看。
以下讨论的参数不涵盖网关gateway、加密参数sign、加密类型sign_type，因为这些都是必须的。
以实物标准双接口为例，可把参数看做几个功能部分组成
不可缺少的参数
service服务参数，这个是用来区别这个接口是用的什么接口，所以绝对不能修改。
partner合作身份者ID、key安全校验码或称私钥这一组参数是签约合同生效后才能拿的到，partner是来鉴别是哪个商家与支付宝签约，而这个Key它如同钥匙般相当重要。
seller_email收款人支付宝账号，支付宝中有手机类型、电子邮件类型的支付宝账号是都可以用这个参数的。
subject在支付宝的收银台里是直接与商品名称关联在一起的，但是说的更准确些的话，这个参数是这笔交易的名称，因为这笔交易不一定只买一件商品。它的作用不仅是在收银台里可以清晰的显示出来，而且在支付宝的账户的交易明细的列表里，它也是排在第一列，由此可推测出，它有财务对账、作为交易查询的筛选条件等诸多作用。非常重要。
out_trade_no技术文档中给出的是商户交易号（确保在商户系统中唯一），顾名思义这个就是我们大家自己网站的订单系统里的唯一订单号，而非支付宝的。这里需要强调的，这个订单号必须得是唯一的，如何唯一法？自己网站里订单系统的订单号是绝对唯一的吧，支付宝要求的唯一就是这个，为什么非要唯一？支付宝会根据订单号来判定这笔订单对于这个商家的所有交易中是否是唯一的。
price金额、quantity数量，这里设置有两种方式一种商品的单价金额，多个数量（即大于等于1）。另种是数量为1，金额代表总额，甚至是包含了运费。为什么大部分的客户要这么做？原因很简单，第一，购物车里的东西不一定是单纯的一件或者多件相同的商品，那么为商品设置金额时就有困难了，因此这里用总额是最好的，而数量就默认为1。第二，运费的设置很多客户是与各家快递公司签约、每件物品的快递费用也不尽相同，为了省去麻烦，在程序计算的时候干脆把运费也加进去。因此我们只需要记住一件事，这个price的金额就是所谓的总额了。
payment_type支付类型，没什么可说的直接写成1，无需改动。
物流信息logistics_type、logistics_fee、logistics_payment这是一组物流信息，实物标准双接口中必须得至少有一组物流信息，也就是指这三个参数了，最多可有三组，哪三组呢？logistics_type_1、logistics_fee_1、logistics_payment_1（第二组）；logistics_type_2、logistics_fee_2、logistics_payment_2（第三组）。后两组为可选项。一般前面有说Price已经是总额了且包含了运费，那么这里物流运费就直接设置成0即可，即logistics_fee=”0”，其他两个的信息可参考技术文档来填写，因为要从技术文档中的枚举列表里来选择，所以绝不可乱填写。
可增加的有用参数
物流信息最多三组，最少一组，这已经在前部分有所提及，这里就不再细说。
_input_charset，当是UTF-8的编码格式时必须得用到且不允许为空的，即_input_charset=”utf-8”
notify_url、return_url，return_url代表支付完毕后可以自动从支付宝的官方页面跳转回来，notify_url这个是防止调单的首选最佳工具。
body，在支付宝收银台中的商品描述里显示，如果subject是订单名称的话，那么这个body则最准确的称之为订单描述，其实个人认为它作为备注之类的更为恰当。很多人都很郁闷支付宝为何不能像其他公司的接口有个自定义的参数来存放客户想要的东西，其实body也具有类似的这种功能，它不仅容纳的信息是所有参数里最大的，而且还是以字符串的形式储存，个人认为它其实也是非常重要的不可缺少的参数之一呢。
discount折扣，顾名思义如果小于0，则是用原金额Price*quantity+(discount)，实际金额便比原总额小了。现在有些商户有支付宝的优惠卷，而优惠卷的用途也是在这个参数中体现，具体做法与前面无异。
show_url商品展示地址，这个链接的作用是在支付宝收银台的商品链接旁边有个下划线“详情”的链接，而点链接弹出的一个新页面便是这个商品展示地址的页面。
收货信息receive_name、receive_address、receive_zip、receive_phone、receive_mobile，这些信息若也设置为传递给支付宝的参数之一的话，那么在支付宝收银台点选下一步的时候，本该出现的填写收货信息页面不见踪影，而直接跳到了收货信息页面的下一个页面去了。很多商户在自己的网站的购物流程中都有一个填写收货信息的选项卡，为了省去到支付宝收银台中还要填写一次收货信息的麻烦，那么这些收货信息的参数就派上用场了。值得注意的是，收货人姓名和地址是必填项，不然还是会出现收货信息填写页。
buyer_email买家支付宝账号，这个设置好后呈现的效果便是，原本是空的支付宝账号的输入框此时已经有个支付宝账号在里面放置。
剩下的参数无需理会
整个实物标准双接口的参数介绍完毕，那么其他接口的参数还要介绍吗？大家从上面分析得出的东西对比技术文档的参数列表是否看出什么来了？
参数列表的最后一列叫“可空”，N代表不允许为空，Y代表允许为空，结合上面的不可缺少参数与增加的有用参数来进行比较，不难发现，不可缺少的参数全是为N的。
有些为Y的参数有一组，例如buyer_email、buyer_id，凡是遇到这种的一般都是二可选一也可都不选，或是二必选一。举例说明：二必选一的是seller_email、seller_id，二选一的是buyer_email、buyer_id。
所有的接口的参数如此分析就能判断出哪些是重要参数哪些可不要，结合技术文档与程序接口来研究就能一目了然。
传递给支付宝时的return_url参数所对应的页面文件。
具备的属性：
1、支付接口中买家的购买流程已经走到支付宝里且支付宝提示支付成功时，页面会自动跳转回自身网站的这个页面里来。
2、同步的，无时差
3、获得参数的方法是用get方式获取。
4、不论跳转回来程序判断是真还是假（if(sign = mysign and responseTxt = true)）只跳转回来一次，不重复。
5、这个并不是支付宝服务器调用了该页面，而是通过与组合拼接各参数形成的URL链接原理等同，拼接出来的URL链接，之后程序上做自动跳转。
6、基于5的原因，该页面的程序调试可不必在服务器上而是本机上调试、运行。
传递给支付宝时的notify_url参数所对应的页面文件
具备的属性：
1、这个通知页就是被支付宝调用才能启动的。
2、服务器间的互动，不像返回页肉眼可以看到，这个是看不到的。
3、获得参数的方法是用POST方式获取。
4、支付宝中的该笔交易存在，且该笔交易状态发生了变更，就会被调用。
5、被调用程序判断（if(sign = mysign and responseTxt = true)），若我们自己在该判断中有做程序编写，成功则不再被调用，不成功则会反复被调用。
6、异步的，第一次收到订单信息（以下都称之为“通知”）是与返回页近乎等同或等同的同步时间，在判断不成功的情况下，会收到第二次第三次等次数的通知，时间间隔从最先的一两分钟，到后面的几个小时。失效时间是48小时。
7、基于6的原因，该页面的程序调试必须在服务器上调试、运行。
8、程序编写时必须采用程序执行成功，才写页面response.Write(“success”);，不成功则写页面response.Write(“fail”); 支付宝根据success来判定是否要重新再次发送通知。
9、该页面的Html页面中必须是空白、无任何Html标签、无任何空格、不允许做页面跳转。
以C# ASP.NET实物标准双接口代码为例：
[csharp] view plaincopy
if (mysign == sign && responseTxt == "true")
if (Request.Form["trade_status"] == "WAIT_BUYER_PAY")//
判断支付状态_等待买家付款（文档中有枚举表可以参考）
//更新自己数据库的订单语句，请自己填写一下
else if (Request.Form["trade_status"] == "WAIT_SELLER_SEND_GOODS")//
判断支付状态_买家付款成功,等待卖家发货（文档中有枚举表可以参考）
//更新自己数据库的订单语句，请自己填写一下
string strOrderNO = Request.Form["out_trade_no"];//订单号
string strPrice = Request.Form["price"];//金额
string sql = "update order_table set order_status = '买家已付款，等待卖家发货' where order_no = @out_trade_no";
Update(sql,para);
else if (Request.Form["trade_status"] == "WAIT_BUYER_CONFIRM_GOODS")//
判断支付状态_卖家已发货等待买家确认（文档中有枚举表可以参考）
//更新自己数据库的订单语句，请自己填写一下
string strOrderNO = Request.Form["out_trade_no"];//订单号
string strPrice = Request.Form["price"];//金额
string sql = "update order_table set order_status = '卖家已发货，等待买家确认收货' where order_no = @out_trade_no";
Update(sql, para);
else if (Request.Form["trade_status"] == "TRADE_FINISHED")//
判断支付状态_交易成功结束（文档中有枚举表可以参考）
//更新自己数据库的订单语句，请自己填写一下
string strOrderNO = Request.Form["out_trade_no"];//订单号
string strPrice = Request.Form["price"];//金额
string sql = "update order_table set order_status = '交易成功' where order_no = @out_trade_no";
Update(sql, para);
//更新自己数据库的订单语句，请自己填写一下
Response.Write("success");
Response.Write("fail");
在支付宝的众多接口中，不是所有的接口都拥有通知页与返回页的。
有的接口只有返回页；有的接口有通知页且用XML格式的内容显示在当前页面中；有的没有通知页也没有返回页仅仅只以XML格式的内容显示在当前页面中。所以，我们要根据各接口的技术文档与程序实例来做相应的数据处理。
大家这里存在一个疑问，一般大家的做法都是把数据库更新些在返回页中，但是很多情况下出现了订单不同步即掉单现象。这是为什么？
答：返回页是当前页面自动跳转的，这虽然跳转的反应速度不错，但人的手动关闭该页面操作绝对可以使之在没有跳转回来之前就关掉了该页面，此时原本该数据库更新的程序并没有被启动，这样直接导致了掉单，所以一般大商户，尤其是网络游戏行业的即时到帐充值的技术做法是：返回页中有订单处理程序，通知页中也有，当返回页中的订单没做过处理时，通知页中的数据处理程序便启动；这样即可近乎100%解决掉单问题（还有种掉单原因是大家自己的服务器出现问题，比如MS3XML.DLL问题，这个问题至今没有什么可以解决的办法，只能重装或是更换服务器，也有的服务器因为中毒才导致的）。
接入部分做好了，通知返回部分也做好了，那么开始调试吧。
调试也分成两大部分来做。
部分网站用了框架模式frame，但这个并不适用支付宝的接口程序，因此绝对不能把支付宝的接口页面置于整个网站的框架之下。
确定好要用POST还是GET方式来传递参数，二者不能混用。由于有些网站中不一定只有一个接口入口，所以整个网站都必须保持一致性，不能这个接口用POST，那个接口用GET，这样直接导致后续出现一系列连查找原因都极其困难的现象。
接入部分的调试工作，则是输入支付宝要求的格式的值，如subject、body的值不允许有非法字符、金额格式必须是小数点后两位数或是正整数且不是金额格式（即$123.00），以及非常重要的一个原则，传递的参数要么不传递这个参数（即传递的众多参数中，这个参数完全不存在），要么这个参数不允许为空。很多人在调试时支付出现一系列“调试错误”有很大的一部分原因就是参数的设置存在问题。
编码格式一定要确认再确认，在支付时直接出现“调试错误，SIGN不对”只有两种原因，一是C部分已提到的参数的设置问题，另一个便是这个编码格式的问题。编码格式是非常重要的，绝对不能这个地方用GBK，另个地方用utf-8。
通过接口走一次真实的操作，若是支付接口，则走一笔真实的交易，金额则是0.01元（支付宝是没有测试环境的，所以请老实的使用自己签约的号去走真实交易），不要觉得很麻烦，也不要把这个工作交个经理或者你的老板来做，因为它直接关系到你后续的操作步骤与调试的顺畅程度。
返回部分在本机电脑上就可以调试完毕，之前有提到不要把支付测试工作交给自己以外的其他人，这里就可以得到充分的说明，不论是哪种语言都拥有自己风格的单步监控程序代码的能力，返回部分就要一步一步监控程序的执行，确保1、是否执行到了“mysign == sign && responseTxt == “true””，这个IF语句的判断；2、是否进入了这个语句里而不是else里；3、数据库更新程序是否执行成功，而不是卡着不动了；4、数据库更新完毕后，程序是否走完。基本出现问题的地方就在第一步，所以不要觉得奇怪为什么掉单？
通知页的调试，这个调试就比较麻烦了，首先这个支付宝接口已经完成且放在了服务器上，别人可以通过互联网来进行支付；其次，要把通知页中的“写日志”程序启动起来，日志内容主要记录trade_status、trade_no、out_trade_no、price、sign、mysign、responseTxt等。一般出现的原因依旧是“mysign == sign && responseTxt == “true””这个判断上不被通过。
具体检测方式：
1、直接用互联网访问
访问是否能够访问得到，且显示”fail”的字眼，其他如空白或是其他程序错误提示等内容，均属程序执行出错。
2、程序是否执行到，sign=mysgin and responseTxt = “true”这个判断中，如果执行到这个判断时跳到ELSE的判断语句去了，则表示您的接口程序在支付时传递的参数信息或是您的编码格式、合作身份者ID与安全校验码的设置存在问题。
3、程序已经执行到sign=mysgin and responseTxt = “true”这个判断中，却没有执行到response.Write(“success”)这句话，说明您自己编写进去的程序代码执行出错，请检查。
有些接口，例如支付的接口，是支持POST或者GET方式传递参数的。
POST传递方式：
这里需要注意的地方是：&form action=” aliay_url” …&中action的值是网关+编码格式参数，即? _input_charset=utf-8，GBK的编码格式可以为：?。
GET传递方式：
是用&字符来连接起来的一长串URL链接字符串，通过自动跳转不是&form action=” aliay_url” …&的方式来存放，而是用Response.Redirect(aliay_url)方式来进行跳转。
没有更多推荐了，