TxShield can process many different types of transactions that use 3 main different transaction workflows / lifecycles for many different payment methods.
Transaction Types
PAYMENT Transactions
Are instant & synchronous and are typically associated with a credit card transaction such as Visa or Mastercard.
PREAUTH/SETTLEMENT
Are asynchronous transactions. They are used to authorise a transaction that doesn't immediately get settled (PREAUTH). These transactions can be settled either manually or using a postback from the gateway side (SETTLEMENT). Examples are ACH, Bank deposits, wire transfers.
AUTH/CAPTURE
Are the same as a PREAUTH/SETTLEMENT but updated to avoid using the phrase SETTLEMENT, which can cause confusion about the payment status.
CREDIT Transactions
Are transactions in which funds are credited to a recipient's credit card. They are asynchronous transactions
VOID Transactions
Are used to void a transaction. If the transaction amount has not been settled /transferred to the merchant's account, there is a chance the transaction can be voided. This typically has lower processing fees than a REFUND. Not all gateways support VOID transactions.
REFUND Transactions
Once a transaction has been settled / transferred to the merchant account, the transaction can no longer be VOID, so any reversals must be done via a REFUND transaction.
Each Transaction Type has a matching set of of workflow and Integration methods. They are mapped out below.
Transaction Type | Synchronous / Asynchronous / Redirect | Integration Methods |
---|---|---|
PAYMENT | Synchronous / Redirect | REST, SOAP, FORM REDIRECT / SUBMIT |
PREAUTH/SETTLEMENT | Asynchronous / Redirect | REST, SOAP, FORM REDIRECT / SUBMIT |
AUTH/CAPTURE | Asynchronous / Redirect | REST, SOAP, FORM REDIRECT / SUBMIT |
CREDIT | Asynchronous | REST, SOAP |
VOID | Synchronous | SOAP |
REFUND | Synchronous | SOAP |
Payment Methods
TxShield has an extensive list of available Payment Methods. The Payment Method is a guide for which fields TxShield will be expecting / looking at. A single Integration can have several Payment Methods available, and to distinguish between which one is being used, it is sent in in the payby
/card_type
parameters.
Common current Payment Methods are
- Mastercard
- Visa
- VMC (combined Visa / Mastercard)
- CUP
- JCB
- UPOP
- AMEX
- DINERS
- DISCOVER
- REDIRECT
- ONLINEPAYMENTS
- BANK
- ACH
- WIRE
Transaction Lifecycle / Transaction Workflow
Synchronous

- Customer completes a purchase on merchant site.
- Merchant sends all required purchase data to TxShield
- TxShield processes the purchase and sends a payment request to the Customers Issuing Bank
- The Issuing Bank sends back whether the payment was successful or not.
- TxShield returns the completed payment details to the merchant's system.
Synchronous Transactions are instant payment transactions where the whole transaction life cycle is completed in one call. They are typically associated with credit card transactions such as Visa / Mastercard / CUP / JCB.
Synchronous payments are typically associated with the PAYMENT transaction type. VOID and REFUND are also synchronous calls.
Asynchronous

- Customer completes a purchase on merchant site.
- Merchant sends all required purchase data to txShield
- TxShield processes the purchase and sends a payment request to the Customers Issuing Bank
- The Issuing Bank sends back an acknowledgment that they have received the payment request. This does not indicate if payment is successful. Just that they have received the request.
- TxShield returns whether the bank has acknowledged the payment request.
- The Issuing Bank sends a notification that the payment is now complete and whether it was successful or not.
- TxShield processed the payment notification and sends a notification to the merchant's system that payment is now complete, and whether it was successful or not.
Asynchronous transactions are more complex than synchronous transactions integrations but offer a lot more flexibility and integration types.
Common use cases are for Bank / Wire transfers where a transaction Id is generated and the customer has to manually transfer the money with that transaction Id as a reference, or go to a physical payments office to complete the payment.
When the payment has been confirmed, the Issuing Bank / Payment processor can automatically trigger a call at step 6 confirming payment is complete. In the case of a local Bank Transfer, you may even need to manually acknowledge the settlement in the txShield system and mark the transaction as complete, and TxShield will complete step 7.
Redirect

- Customer completes a purchase on merchant site.
- Merchant sends all required purchase data to txShield via either a form submit, or a form redirect. Sending the user's browser to the TxShield server.
- TxShield processes the purchase data and forwards the user's browser to the Intermediary Hosted Form. This could be a different payment processors' hosted form allowing the user to enter credit card details, or an online wallet system that requires the user to validate the purchase request by logging in and confirming payment.
- If required, after submitting the intermediary form the payment will be sent to the issuing bank.
- The issuing bank will send back the status of the payment request. To the Intermediary
- The Intermediary will forward the status of the payment to TxShield
- TxShield will return the status of the payment, along with the browsers window, to the Merchants system.
The redirect workflow requires that the user's browser window is redirected to the TxShield server, and will be redirected again to some intermediate form before the transaction is complete. Redirect transactions can either by Synchronous or Asynchronous in nature. Meaning that you could have the final transaction status at the completion of the redirect flow, or you could be waiting for a SETTLEMENT/CAPTURE to come in later. It will depend on the type of integration and payment methods being used.
Common use cases for the Redirect workflow can be for using third-party wallets, where the user has an online balance that they wish to use to complete payment. Redirecting the user to another payment provider online payment form etc.