AllinPay Agreement Payment Flow

Problem It Solves

Integrating AllinPay agreement payments is less about calling one API and more about handling a state machine: signing, debit, refund, and query depend on different sequence numbers; response codes are scattered; 0000 and 4000 can both mean success; 2000, 2007, 2008, 1108, and 1000 require follow-up query; HTTPS timeouts must not be treated as failure. This skill targets backend Java projects and turns AllinPay SDK docs, examples, and response-code rules into implementable call code.

How It Works

The skill generates code along the business chain rather than isolated interface snippets:

• Signing: call 310001 to trigger the SMS verification, save REQ_SN; then call 310002 to validate the code and obtain AGRMNO.
• Payment: use 310011 with the agreement number to start debit, save the transaction sequence, and decide whether 200004 query is needed.
• Query: use 200004 for both payment and refund, with special handling for 1002, processing states, and detail return codes.
• Refund: use REFUND, keeping refund business codes separate from agreement-payment business codes.

Generated code should prefer SDK helpers such as isTrxSuccess(), isTrxFailed(), and getErrMsg(); for query responses in SDK 1.0.2, use QueryDetail.isSuccess() for each detail record.

Boundaries and Caveats

This is suitable for Java projects that already have the AllinPay SDK, merchant code, business codes, and key files. Do not treat merchant IDs, card numbers, or verification codes in examples as real credentials. The test-environment SMS code is fixed as 111111 and only for integration testing; production must use real SMS, real keys, and real business codes. For SM2 or RSA signatures, the signature type must match the key format, and p12 private keys require a password.