Magento 微信支付

Magento 微信支付

根据前面几节介绍的微信支付分析这里大致介绍一下magento中微信支付功能的编写思路,用户可以选择微信支付(JsApi)也可以选择微信扫码支付(Native).
首先在magento 的app/code/local 下创建模块 并在 module设置active 为true
大致目录结构如图
这里写图片描述
转载请注明出处:http://blog.csdn.net/m0sh1/article/details/45449679
编写 etc/system.xml 为后台配置模块
可以将微信支付所需要的 appid appsecret mchid 和 key等信息配置到这里。这样在后台启用这个模块就会在前台支付过程中显示这个支付方式了。
当我们点击确认支付的时候 其实是调用了相关支付方式Model中的
getOrderPlaceRedirectUrl() 函数。我们可以在这个函数中设定下一步要走的流程。
例如:

public function getOrderPlaceRedirectUrl()
    {
        return Mage::getUrl('wxpay/wxselect');
    }

即调用 WxselectController.php 中的indexAction()方法,一般其它支付是直接跳转到相应的PaymentController.php 中的redirectAction() 方法,这里这么做的目的是展示给用户一个选择支付方式的页面。因为如果用户在PC端打开或者在移动浏览器中打开是不能使用微信JsApi支付的,(即使在微信中还可能存在跨号支付的问题)所以同时展示出来微信扫码支付的支付方式,当然你可以在代码上通过判断智能的实现支付方式的选择。
在选择页面用户选择了支付方式后,跳转到 PaymentController.php中的indexAction() 方法中。
核心代码如下:

$order = $this->getOrder();
if (!$order->getId())
{
    $this->norouteAction();
    return;
}

$order->addStatusToHistory(
    $order->getStatus(),
    Mage::helper('customer')->__('微信支付')
);

$order->save();

$this->getResponse()
    ->setBody($this->getLayout()
        ->createBlock('wxpay/redirect')
        ->setOrder($order)
        ->toHtml());

程序实例化 Block 展示微信支付页面。在Block 中获取order

$order = $this->getOrder();

JsApi 所需要的参数 通过Model 获取

$jsApiParameters = $model->createPackageInfo($order,$currentUrl);

如果是Native 方式则代码为:

$urlParam = $model->createPackageInfoNative($order);

因为微信支付需要设定支付发起的目录(具体可参见前面的微信支付相关文章)并且只有在这个目录下支付才能生效。
而magento(很多mvc 框架都是)是通过router形式运行的。我大致测试了一下设定支付目录就是 controller下的一个方法,支付没有成功,也可能我编写的有不对的地方,总之没有继续深究,而是干脆把支付放到了magento 根目录下的自定义目录下,例如是wxp目录。
这时候要做的操作就是微信支付所需要的参数 以get形式传递给相应的支付发起文件就可以了。(get形式就可以了,看了应该下没有什么需要保密的内容,有建议欢迎指出。)
例如 jsapi方式那么直接创建文件 jsapi.php
部分代码:

<?php
$jsApiParameters=$_GET['jsApiParameters']
?>

然后将参数传给 js 就可以了
同理 native.php
最后就是 编写 notify 函数,我设定的notify都是通知给 PaymentController.php中的notifyAction()方法
部分代码:

$notify = new PayNotifyCallBack();
$resCheck = $notify->Handle(false);
if($resCheck){
// 验证签名等成功
$xmlBackData = $GLOBALS['HTTP_RAW_POST_DATA'];
$array_data = json_decode(json_encode(simplexml_load_string($xmlBackData, 'SimpleXMLElement', LIBXML_NOCDATA)), true);
$out_trade_no = $array_data['out_trade_no'];
$model = Mage::getModel('wxpay/payment');
$order = Mage::getModel('sales/order')->loadByIncrementId($out_trade_no);
// 获取到了order 那么此时就可以对这个order 做状态更改了

大致思路就是这样,这是第一次使用CSDN 的MarkDown 编辑器编写的使用起来还不错 ╭(′▽`)╯
转载请注明出处:http://blog.csdn.net/m0sh1/article/details/45449679

 

 

此文章通过 python 爬虫创建,原文是自己的csdn 地址: Magento 微信支付

 

Magento SUPEE 6788

SUPEE-6788 is a bundle of patches that resolve several security-related issues.

Note: this patch bundle may possibly break backward compatibility with customizations or extensions. Please check the

technical details
page.

You can find more details on the vulnerabilities address by this patch below:

Error Reporting in Setup Exposes Configuration - APPSEC-1102

Type:

Information Leakage (Internal)

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Error messages generated during the Magento installation, or during a failed extension installation, can expose the Magento configuration and database access credentials. In most cases, the database server is configured to prevent external connections. In
other cases, the information can be exploited, or tied to another attack.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Albert Assmann

Filter Directives Can Allow Access to Protected Data - APPSEC-1057

Type:

Information Leakage

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Email template filter functionality can be used to call blocks exposing customer information like last orders or integration passwords. While this functionality is used internally in Magento safely, we were informed about external extensions that use it
to process user input like blog comments. This allows to access protected information from store front.

Note: technical details on this issue are available
here
.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Peter O'Callaghan

XXE/XEE attack on Zend XML functionality using multibyte payloads - APPSEC-1045

Type:

XXE/XEE (XML Injection)

CVSSv3 Severity:

7.5 (High)

Known Attacks:

None

Description:

Magento can be forced to read XML via API calls containing ENTITY references to local files, possibly reading password or configuration files. While Zend Framework filters out ENTITY references, they can be encoded as multi-byte characters to avoid detection.

This is a Zend Framework issue described here http://framework.zend.com/changelog/1.12.14/

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Dawid Golunski

Potential SQL Injection in Magento Core Model Based Classes - APPSEC-1063

Type:

SQL Injection

CVSSv3 Severity:

7.4 (High)

Known Attacks:

None

Description:

addFieldtoFilter method does not escape field name. Although core Magento functionality is not affected, this issue might impact third-party extensions such as layered navigation extensions. Such extensions might be exploited from the storefront to execute
any SQL queries. 

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Jim O'Halloran/Aligent

Potential remote code execution using Cron - APPSEC-1037

Type:

Remote Code Execution (RCE)

CVSSv3 Severity:

7.2 (High)

Known Attacks:

None

Description:

Cron.php script is available for anyone to call and itself calls command line functions. It makes is a possible target for the Shellshock vulnerability (which should be fixed on the server). Additionally, the command passed to shell is not escaped, which
in case of a directory named as a shell command can result in code execution – such attack requires however additional access to create directories with arbitrary names, like hosting panel. While scored as high, the attack is not exploitable by itself.

Product(s) Affected:

Magento CE 1.8.0.0 - 1.9.2.1, and Magento EE 1.13.0.0 - 1.14.2.1

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Dawid Golunski

Remote Code Execution/Information Leak Using File Custom Option - APPSEC-1079

Type:

Remote Code Execution/Information Leak

CVSSv3 Severity:

6.5 (Medium)

Known Attacks:

None

Description:

Custom option values are not cleared when the custom option type is switched. This makes it possible to inject malicious serialized code into a custom option of the “text” type, and execute it by switching the custom option type to “file.”

To exploit this remote code execution attack the store has to use custom options and a store administration account with access to catalog/products.

Additionally, manipulation of custom options from the storefront makes it possible to read system files if store uses custom options.

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Peter O'Callaghan

Cross site scripting with error messages - APPSEC-1039

Type:

Cross-site Scripting (CSS) - reflected

CVSSv3 Severity:

6.1 (Medium)

Known Attacks:

None

Description:

Error messages on store front pages are not escaped correctly, enabling self XSS issue.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Ultra Security

Potential remote code execution using error reports and downloadable products - APPSEC-1032

Type:

Remote Code Execution (RCE)

CVSSv3 Severity:

6.1 (Medium)

Known Attacks:

None

Description:

It is possible to put unvalidated information (including code) into error report files. This attack could be tied with potential other attacks to execute the code in the report files. This issue is not exploitable itself.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Hannes Karlsson

 

Admin Path Disclosure - APPSEC-1034

Type:

Information Leakage (Internal)

CVSSv3 Severity:

5.3 (Medium)

Known Attacks:

None

Description:

Attacker can force showing admin panel login page regardless of admin panel URL by calling a module directly. It makes it easier to try automated password attacks and exposes admin URL on the page.

 

Note: technical details on this issue are available here.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Nils Preuss

Insufficient Protection of Password Reset Process - APPSEC-1027

Type:

Account Takeover

CVSSv3 Severity:

3.8 (Low)

Known Attacks:

None

Description:

The token to reset password is passed via a GET request and not cancelled after use. This means it leaks in the referrer field to all external services called on the page (image servers, analytics, ads) and can be potentially reused to steal customer password.

Product(s) Affected:

Magento CE prior to 1.9.2.2, and Magento EE prior to 1.14.2.2

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Vishnu Dfx

Dev Folder Not Protected - APPSEC-1124

Type:

Information Leakage (Internal)

CVSSv3 Severity:

0.0 (None)

Known Attacks:

None

Description:

The Magento dev folder, including functional tests, lacked a proper .htaccess file to prevent browser access. As a best practice, all files and directories that are not intended for public view should be protected.

Product(s) Affected:

Magento CE 1.9.2.0-1.9.2.1, and Magento EE 1.14.2.0-1.14.2.1

Fixed In:

CE 1.9.2.2, EE 1.14.2.2

Reporter:

Internal

For Magento Community Edition only prior to version 1.9.2.1:

Cross-site Scripting/Cache Poisoning - APPSEC-1030

Type:

Cross-site Scripting (XSS) - Stored / Cache Poisoning

CVSSv3 Severity:

9.3 (Critical)

Known Attacks:

None

Description:

Unvalidated host header leaks into response and page. Because the page can be cached, this leak poses a risk for all store customers because any HTML or JavaScript code can be injected. Such an exploit works only with specific server configurations, and
allows an attacker to intercept a session or modify a page with fake credit card forms, etc.

Note: While this issue is not applicable to out of the box Magento Community installations, it could possibly be exploited with 3rd party full page caching extensions. This patch was also already included in 1.9.2.1 release.

Product(s) Affected:

Magento CE prior to 1.9.2.1

Fixed In:

EE 1.14.2.1

Reporter:

Internal (ECG)

此文章通过 python 爬虫创建,原文是自己的csdn 地址: Magento SUPEE 6788

Nginx重定向[Rewrite]配置

nginx rewrite 各参数意义

$arg_PARAMETER #这个变量包含GET请求中,如果有变量PARAMETER时的值。

$args #这个变量等于请求行中(GET请求)的参数,例如foo=123&bar=blahblah;

$binary_remote_addr #二进制的客户地址。

$body_bytes_sent #响应时送出的body字节数数量。即使连接中断,这个数据也是精确的。

$content_length #请求头中的Content-length字段。

$content_type #请求头中的Content-Type字段。

$cookie_COOKIE #cookie COOKIE变量的值

$document_root #当前请求在root指令中指定的值。

$document_uri #与$uri相同。

$host #请求主机头字段,否则为服务器名称。

$hostname #Set to the machine’s hostname as returned by gethostname

$http_HEADER

$is_args #如果有$args参数,这个变量等于”?”,否则等于””,空值。

$http_user_agent #客户端agent信息

$http_cookie #客户端cookie信息

$limit_rate #这个变量可以限制连接速率。

$query_string #与$args相同。

$request_body_file #客户端请求主体信息的临时文件名。

$request_method #客户端请求的动作,通常为GET或POST。

$remote_addr #客户端的IP地址。

$remote_port #客户端的端口。

$remote_user #已经经过Auth Basic Module验证的用户名。

$request_completion #如果请求结束,设置为OK. 当请求未结束或如果该请求不是请求链串的最后一个时,为空(Empty)。

$request_method #GET或POST

$request_filename #当前请求的文件路径,由root或alias指令与URI请求生成。

$request_uri #包含请求参数的原始URI,不包含主机名,如:”/foo/bar.php?arg=baz”。不能修改。

$scheme #HTTP方法(如http,https)。

$server_protocol #请求使用的协议,通常是HTTP/1.0或HTTP/1.1。

$server_addr #服务器地址,在完成一次系统调用后可以确定这个值。

$server_name #服务器名称。

$server_port #请求到达服务器的端口号。

$uri #不带请求参数的当前URI,$uri不包含主机名,如”/foo/bar.html”。该值有可能和$request_uri 不一致。$request_uri是浏览器发过来的值。该值是rewrite后的值。例如做了internal redirects后。

今 天在给某网站写rewrite重定向规则时,碰到了这个关于重定向的参数处理问题。默认的情况下,Nginx在进行rewrite后都会自动添加上旧地址 中的参数部分,而这对于重定向到的新地址来说可能是多余。虽然这也不会对重定向的结果造成多少影响,但当你注意到新地址中包含有多余的“?xxx=xxx”时,心里总还是会觉得不爽。那么该如何来处理这部分的内容呢?看了下面两个简单的例子你就会明白了。

例如:
http://example.com/test.php?para=xxx 重定向到 http://example.com/new
若按照默认的写法:rewrite ^/test.php(.*) /new permanent;
重定向后的结果是:http://example.com/new?para=xxx
如果改写成:rewrite ^/test.php(.*) /new? permanent;
那结果就是:http://example.com/new

所以,关键点就在于“?”这个尾缀。假如又想保留某个特定的参数,那又该如何呢?可以利用Nginx本身就带有的$arg_PARAMETER参数来实现。

例如:
http://example.com/test.php?para=xxx&p=xx 重写向到 http://example.com/new?p=xx
可以写成:rewrite ^/test.php /new?p=$arg_p? permanent;

只求结果的朋友可以直接忽略前面的内容,看这里:

rewrite  ^/test.php  /new  permanent;       //重写向带参数的地址

    rewrite  ^/test.php  /new?  permanent;      //重定向后不带参数

    rewrite  ^/test.php   /new?id=$arg_id?  permanent;    //重定向后带指定的参数

permanent是永久重定向参数,根据需要去掉也可以,不过最好是带有。
参考301重定向与302重定向的区别

首先Apache的Rewite规则差别不是很大,但是Nginx的Rewrite规则比Apache的简单灵活多了
Nginx可以用if进行条件匹配,语法规则类似C

if ($http_user_agent ~ MSIE) {
rewrite ^(.*)$ /msie/$1 break;
}

Rewrite的Flags

Flags can be any of the following:
* last - completes processing of rewrite directives, after which searches for corresponding URI and location
* break - completes processing of rewrite directives
*redirect - returns temporary redirect with code 302; it is used if the substituting line begins with http://
* permanent - returns permanent redirect with code 301

last – 完成重写指令后,搜索相应的URI和位置。相当于Apache里的[L]标记,表示完成rewrite,不再匹配后面的规则。
break – 中止Rewirte,不在继续匹配。
redirect – 返回临时重定向的HTTP状态302。
permanent – 返回永久重定向的HTTP状态301。

ZEND Framework的重定向规则:
案例一:
全部重定向到 /index.php

rewrite ^/(.*) /index.php?$1&;

案例二:
如果文件或目录不存在则重定向到index.php

if (!-e $request_filename) {
rewrite ^/(.*) /index.php?$1&;
}

WordPress的重定向规则:
案例一:
http://www.wemvc.com/12 重定向到 http://www.wemvc.com/index.php?p=12

if (!-e $request_filename) {
rewrite ^/(.+)$ /index.php?p=$1 last;
}

案例二:
与zendframework配置很像

if (!-e $request_filename) {
rewrite ^/(.*) /index.php?$1&;
}

以下为Discuz完整的Rewrite for Nginx规则

if (!-f $request_filename) {
rewrite ^/archiver/((fid|tid)-[w-]+.html)$ /archiver/index.php?$1 last;
rewrite ^/forum-([0-9]+)-([0-9]+).html$ /forumdisplay.php?fid=$1&page=$2 last;
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+).html$ /viewthread.php?tid=$1&extra=page=$3&page=$2 last;
rewrite ^/space-(username|uid)-(.+).html$ /space.php?$1=$2 last;rewrite ^/tag-(.+).html$ /tag.php?name=$1 last;
}

文件及目录匹配,其中:
-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行

正则表达式全部符号解释
~ 为区分大小写匹配
~* 为不区分大小写匹配
!~和!~* 分别为区分大小写不匹配及不区分大小写不匹配
(pattern) 匹配 pattern 并获取这一匹配。所获取的匹配可以从产生的 Matches 集合得到,在VBScript. 中使用 SubMatches 集合,在JScript. 中则使用 $0…$9 属性。要匹配圆括号字符,请使用 ‘(’ 或 ‘)’。
^ 匹配输入字符串的开始位置。
$ 匹配输入字符串的结束位置。

$(function () {
$('pre.prettyprint code').each(function () {
var lines = $(this).text().split('n').length;
var $numbering = $('

    ').addClass('pre-numbering').hide();
    $(this).addClass('has-numbering').parent().append($numbering);
    for (i = 1; i <= lines; i++) {
    $numbering.append($('
  • ').text(i));
    };
    $numbering.fadeIn(1700);
    });
    });

此文章通过 python 爬虫创建,原文是自己的csdn 地址: Nginx重定向[Rewrite]配置

php 版本 微信支付 APP 服务端开发

我们通过 微信支付的文档知道 第一步 服务端需要调用统一下单接口生成预付单,其中主要的参数就是 prepay_id 这样 app 通过 prepay_id 就可以发起支付请求了。
我们可以参考 微信支付的 官方SDK(就是个坑)
统一下单接口就是 调用函数

WxPayApi::unifiedOrder($input);

其中的一个参数 设置为:

$input->SetTrade_type("APP");

没有服务端demo 可以参考 JSAPI的修改上面的参数就可以了
统一下单接口定义在 WxPay.Api.php中其中有代码

$response = self::postXmlCurl($xml, $url, false, $timeOut);

即向微信接口发送所需要的数据 ,这里面就会出现坑爹的地方。

记得以前版本的 sdk 单词CURLOPT 少些个T
这次是需要把代码

curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,TRUE);

改为

curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,FALSE);

在 WxPay.Data.php中有函数 FromXml($xml)
其中有代码
libxml_disable_entity_loader(true);
这个函数可能引起很大的问题
他的初衷本来是为安全考虑,禁止引用外部xml 网上的一个bug 解释是:

The function 'libxml_disable_entity_loader' is not thread safe so, if a thread configure it to 'true' all the others threads are true too. And it should be at 'false' by default when a new request come. That is why the problem disappears when we restart php-fpm daemon.
If you write this at the beginning of app.php we can see that all is working again:
<?php// app.php
libxml_disable_entity_loader(false);


The problem is caused by some third-party bundle or library, because it must be changing to true and is not restoring to false again.

一些PHP框架使用了这个函数 就会出现问题,我使用magento框架 测试微信支付,添加了这个函数 结果这个服务器上的其它web测试环境都不能够正常访问了。应该就是破坏了整个服务器的load xml 逻辑。
重启服务器后正常,所以我干脆就注释掉了这个函数。
再之后就是得到 prepay_id 后 依照客户端需要的参数给相应参数
但是给客户端的时候需要二次加密
就是在走一遍 加密流程
大致 函数是:

if($order['result_code'] == 'SUCCESS' && $order['return_code'] == 'SUCCESS'){
            $data['appid'] = $order['appid'];
            $data['noncestr'] = WxPayApi::getNonceStr();
            $data['package'] = 'Sign=WXPay';
            $data['partnerid'] = WxPayConfig::MCHID;
            $data['prepayid'] = $order['prepay_id'];
            $data['timestamp'] = time();
            $s = $this->MakeSign($data);
            $data['sign'] = $s;
            $resJson = json_encode($data);
            echo $resJson;

这样客户端就能够正常像微信发送支付请求了。
最后 就是 写好 服务端的 notify函数
根据业务流程 和 notify demo 修改即可

 

此文章通过 python 爬虫创建,原文是自己的csdn 地址: php 版本 微信支付 APP 服务端开发

 

Magento 微信支付

Magento 微信支付

根据前面几节介绍的微信支付分析这里大致介绍一下magento中微信支付功能的编写思路,用户可以选择微信支付(JsApi)也可以选择微信扫码支付(Native).
首先在magento 的app/code/local 下创建模块 并在 module设置active 为true
大致目录结构如图
这里写图片描述
转载请注明出处:http://blog.csdn.net/m0sh1/article/details/45449679
编写 etc/system.xml 为后台配置模块
可以将微信支付所需要的 appid appsecret mchid 和 key等信息配置到这里。这样在后台启用这个模块就会在前台支付过程中显示这个支付方式了。
当我们点击确认支付的时候 其实是调用了相关支付方式Model中的
getOrderPlaceRedirectUrl() 函数。我们可以在这个函数中设定下一步要走的流程。
例如:

public function getOrderPlaceRedirectUrl()
    {
        return Mage::getUrl('wxpay/wxselect');
    }

即调用 WxselectController.php 中的indexAction()方法,一般其它支付是直接跳转到相应的PaymentController.php 中的redirectAction() 方法,这里这么做的目的是展示给用户一个选择支付方式的页面。因为如果用户在PC端打开或者在移动浏览器中打开是不能使用微信JsApi支付的,(即使在微信中还可能存在跨号支付的问题)所以同时展示出来微信扫码支付的支付方式,当然你可以在代码上通过判断智能的实现支付方式的选择。
在选择页面用户选择了支付方式后,跳转到 PaymentController.php中的indexAction() 方法中。
核心代码如下:

$order = $this->getOrder();
if (!$order->getId())
{
    $this->norouteAction();
    return;
}

$order->addStatusToHistory(
    $order->getStatus(),
    Mage::helper('customer')->__('微信支付')
);

$order->save();

$this->getResponse()
    ->setBody($this->getLayout()
        ->createBlock('wxpay/redirect')
        ->setOrder($order)
        ->toHtml());

程序实例化 Block 展示微信支付页面。在Block 中获取order

$order = $this->getOrder();

JsApi 所需要的参数 通过Model 获取

$jsApiParameters = $model->createPackageInfo($order,$currentUrl);

如果是Native 方式则代码为:

$urlParam = $model->createPackageInfoNative($order);

因为微信支付需要设定支付发起的目录(具体可参见前面的微信支付相关文章)并且只有在这个目录下支付才能生效。
而magento(很多mvc 框架都是)是通过router形式运行的。我大致测试了一下设定支付目录就是 controller下的一个方法,支付没有成功,也可能我编写的有不对的地方,总之没有继续深究,而是干脆把支付放到了magento 根目录下的自定义目录下,例如是wxp目录。
这时候要做的操作就是微信支付所需要的参数 以get形式传递给相应的支付发起文件就可以了。(get形式就可以了,看了应该下没有什么需要保密的内容,有建议欢迎指出。)
例如 jsapi方式那么直接创建文件 jsapi.php
部分代码:

<?php
$jsApiParameters=$_GET['jsApiParameters']
?>

然后将参数传给 js 就可以了
同理 native.php
最后就是 编写 notify 函数,我设定的notify都是通知给 PaymentController.php中的notifyAction()方法
部分代码:

$notify = new PayNotifyCallBack();
$resCheck = $notify->Handle(false);
if($resCheck){
// 验证签名等成功
$xmlBackData = $GLOBALS['HTTP_RAW_POST_DATA'];
$array_data = json_decode(json_encode(simplexml_load_string($xmlBackData, 'SimpleXMLElement', LIBXML_NOCDATA)), true);
$out_trade_no = $array_data['out_trade_no'];
$model = Mage::getModel('wxpay/payment');
$order = Mage::getModel('sales/order')->loadByIncrementId($out_trade_no);
// 获取到了order 那么此时就可以对这个order 做状态更改了

大致思路就是这样,这是第一次使用CSDN 的MarkDown 编辑器编写的使用起来还不错 ╭(′▽`)╯
转载请注明出处:http://blog.csdn.net/m0sh1/article/details/45449679

 

此文章通过 python 爬虫创建,原文是自己的csdn 地址: Magento 微信支付