--- id: TST-ACC-TRX-140 title: Integrations processor suite kind: unit product_area: accounting module: transactions revision: 1 status: draft source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 repository: services-accounting files: - modules/transactions/tests/unit/integrations-processor.spec.js implements: [] implements_parts: [] environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 1 isolation: In-memory fixtures and test-controlled collaborators. provenance: test source: >- services-accounting:modules/transactions/tests/unit/integrations-processor.spec.js evidence: - provenance: test source: >- services-accounting:modules/transactions/tests/unit/integrations-processor.spec.js assertion_titles: - the integrations processor (unit) - the call budget (DEF-ACT-0872) - >- lowers the contract’s timeout so the caller’s wait ends 15 seconds before the invocation does - leaves the contract’s own timeout when the invocation has the time - >- sends nothing, unavailable, when the invocation cannot spare a second of budget beyond the reserve - 'a charge (payments.authorize, automatic capture)' - >- passes the pop-up’s session to the tokenization when it handed one back, and the Payrix token as the provider token - >- stores the tokenization’s brand and last four where the authorize names none - >- sends the intent under its key on the merchant account’s connection, and answers the capture with the platform’s marks - >- sends a bank debit as a bank account instrument, by the tenant’s binding when the merchant account binds no connection, and answers it pending settlement - >- charges a bank-account token as an electronic check: the ach feature, pending, the last four, and the bank’s name is no card brand - >- takes the last four and no brand from the tokenization when the authorize of a bank debit names no summary - >- keeps a bank debit pending unless the provider says it cleared, and declines one the bank already rejected - >- declines a token whose kind is not the payment method’s behaviour, charging nothing - >- refuses the charge as declined when the tokenization is refused, and charges nothing - >- throws unavailable, charging nothing, when the tokenization cannot be done - >- answers the provider’s decline with its code, and the customer’s action with the payload - >- maps a failed execution by its class: a decline class is declined, an unavailable class throws with it, unknown is unknown - >- treats an unknown or accepted result as unknown, and retry_later or a gateway refusal as unavailable, nothing charged - >- treats a refusal the gateway answers outside a result as unavailable, and no answer at all as uncertain - a refund (payments.refund) - >- names the authorization on the payment’s connection under the refund’s key with the Rhythm ids, and answers the reference and marks - >- sends the stated reason as metadata, trimmed and cut to the contract’s 200 characters - sends no reason metadata when the stated reason is empty after trimming - >- falls back to the merchant account’s connection and the charge’s reference, answers pending as unknown and a failed refund as declined - a refund that timed out (DEF-ACT-0875) - >- before the send is unavailable, nothing refunded, whether the gateway answers failed or unknown with a timeout - after the send stays unknown for the lookup to reconcile - >- is found by the lookup after the send; a lookup that timed out before the send cannot say, by key or by the provider’s reference - 'a void (payments.void, then payments.refund for a captured charge)' - cancels an uncaptured charge under the reversal’s key - >- refunds a captured charge under the same key with the reversal’s id when the provider refuses the void as captured - >- answers already_settled when the provider refuses the void for another reason, or refuses the refund too - the lookups (payments.lookup) - >- asks for the charge by its key with no connection, and answers the capture, the decline, the action or nothing - >- throws uncertain when the platform cannot say, and unavailable when it cannot look up - >- asks for a refund on the stored connection and answers refunded, pending, failed or not found - >- asks for a pending refund by the provider reference it answered (DEF-ACT-0871) - 'asks for a void as the void, then as the refund it became' - >- reads a bank debit’s clearing from the authorization: cleared on the day asked, returned with the decline, else pending - the context a charge names (WP-W3) - >- names the merchant account and its unit on the tokenization and the authorization - >- names no account on a refund, which runs on the connection the payment was charged on - the pure helpers - >- builds the context from a merchant account’s unit and resource ref, and none without an account - names the keys and the lookup request imports: - 'const { expect } = require(''chai'');' - >- const { localIntegrationTransport, stubInvokeResult, stubGatewayRefusal } = require('@rhythmsoftware/integration-client/local'); - >- const { createTestExecutionContext } = require('@rhythmsoftware/macroservice-testing/execution-context'); - >- const { ProcessorUncertainError, ProcessorUnavailableError } = require('../../services/payments/ports/payment-processor'); - '} = require(''../../services/payments/integrations-processor'');' test_double_declarations: [] --- # Integrations processor suite ## Verification Boundary The suite exercises financial calculations and input contracts in an isolated test process. Registration records the existing executable file; it does not report a run or establish product approval. ## What This Suite Proves The executable assertions exercise this module, but no capability or feature scenario binding is established for this file. Its individual assertion titles remain in the evidence register for subsequent mapping. ## What It Does Not Prove Pure calculations and doubled collaborators do not establish database persistence, route authorization or deployed behavior. An unbound feature chain remains proposed, and this registration carries no execution result. ## Real Dependencies and Test Doubles The imported calculation or contract runs with the fixtures and collaborators declared by the test. The evidence register retains those declarations so the boundaries can be inspected. ## Must Not Be Doubled The calculation or contract being asserted must remain real; replacing it with a predetermined result removes this suite’s evidence.