这边已解决，确认了官方代码是没问题的，但是描述上有个误区，就是API v3密钥，这个秘钥不是提交申请邮件自己商户号对应的秘钥，而是需要联系邮件技术人员，他们会给你一个服务商商户号的秘钥，那个秘钥才是真正用来解密回调数据的真实秘钥

先回答nonce是12位的问题吧，根据[rfc5116](https://tools.ietf.org/html/rfc5116#page-16)，AEAD_AES_256_GCM的nonce的长度是12。

4.  Requirements on AEAD Algorithm Specifications

Each AEAD algorithm MUST accept any nonce with a length between N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are specific to that algorithm.  The values of N_MAX and N_MIN MAY be equal.  Each algorithm SHOULD accept a nonce with a length of twelve (12) octets.  Randomized or stateful algorithms, which are described below, MAY have an N_MAX value of zero.

5.1.  AEAD_AES_128_GCM

   The AEAD_AES_128_GCM authenticated encryption algorithm works as
   specified in [GCM], using AES-128 as the block cipher, by providing
   the key, nonce, and plaintext, and associated data to that mode of
   operation.  An authentication tag with a length of 16 octets (128
   bits) is used.  The AEAD_AES_128_GCM ciphertext is formed by
   appending the authentication tag provided as an output to the GCM
   encryption operation to the ciphertext that is output by that
   operation.  Test cases are provided in the appendix of [GCM].  The
   input and output lengths are as follows:

      K_LEN is 16 octets,

      P_MAX is 2^36 - 31 octets,

      A_MAX is 2^61 - 1 octets,

      N_MIN and N_MAX are both 12 octets, and

      C_MAX is 2^36 - 15 octets.

5.2.  AEAD_AES_256_GCM

   This algorithm is identical to AEAD_AES_128_GCM, but with the
   following differences:

      K_LEN is 32 octets, instead of 16 octets, and

      AES-256 GCM is used instead of AES-128 GCM.

如图的" mac checkin GCM failed"错误提示，是指解密时校验消息的完整性不通过，可能是密文/nonce/associated_data不完整或者传错了（示例函数入参名和json中字段名是一致的），当然也有可能是密钥不正确。

结合其他实现也解密失败，感觉不一定是解密实现的问题。建议你提供一下你调用解密函数的代码，这样能方便找到你的问题。你也可以单独对这段代码进行测试，找个在线的工具随意生成一下密文，再调用函数看看能否解密成功。

另外，示例代码中确实没有版本信息，最新BouncyCastle 1.8.6.1应该没有问题，参考https://www.nuget.org/packages/BouncyCastle/通过nuget获取试试。具体的信息，我们测试之后再补充。

你好，这个问题解决了吗？我现在也出现了这样得问题