Skip to main content

Credit Card Internet Payment Guide using Transaction Processing - For Online Payment Websites

Introduction​

In this guide we will be walking you through how to create single credit card payments initiated by an end user through the internet using the Transaction Processing web service. Our objective will be to establish the basics by using specific credit card payment type examples, however the examples should provide you with the information needed to customize to your specific needs. Internet Payments are initiated and authorized via the internet by the end-user. Credit card payments are those payments against card brands such as Visa or Mastercard accounts. If you have a customer facing online platform where users can login and initiate payments from their credit cards, you will want to follow this guide for proper payment routing.

Getting Started​

Here's what you'll do in this guide

Create a single credit card payment with custom data and customer data.

Prerequisites needed before continuing

  • You will want to obtain your test credentials in order to try any of the examples in this guide. You should have received these from your Implementation Coordinator.
  • Review the Authentication guide for an understanding on how to authenticate to the EPS web service. This guide will walk you through sending a test connection and test credentials to ensure you are able to authenticate before moving forward.
  • Download the Transaction Processing WSDL file from the Downloads menu

Create a single credit card payment with custom data workflow guide​

For this guide we will walk through a hypothetical example where a customer is making a one-time payment of 25 dollars for purchasing a product that they have initiated through a customer facing website. We have given the product an ID of A1234 which we will track with the transaction. The customer is supplying their credit card account information for the payment and we will also capture the user's address information as part of the payment.

  • Step 1 The first thing that will need to occur is to capture the required payment information needed to build the web request. For this example, we will say the customer has entered the following on the website.

    • Name: Test User
    • Address: 1234 Avenue, Allen TX, 75050
    • Card Account: 4111111111111111
    • Amount: 25.00 purchase amount.
    • Product ID: A1234 from product selection
    • Card Expiration: 4/22
    • CVV: 3123

  • Step 2 Using the collected information, we will populate an AuthorizeTransaction request in order to process this payment.

    • Since we have specific user information, we want to add that to the various customer fields.
    • We will also add the productid they purchased to Field1 so it will be stored with the transaction and can be reported on in Transaction Reporting.
    • Since this is an internet payment, we need to specify "Internet" as the "PaymentOrigin".
    • Since this user is making a payment, we will specific "Sale" as the "OperationType".
    • Lastly, we will specify "Card_Transfer" as the "SettlementType".

Here is what our completed AuthorizeTransaction request will look like for this example.

</soapenv:Envelope> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:pv="https://ssl.selectpayment.com/PV">
    <soap:Header/>
    <soap:Body>
        <pv:AuthorizeTransaction>
            <pv:storeId>Your StoreId</pv:storeId>
            <pv:storeKey>Your StoreKey</pv:storeKey>
            <pv:transaction>
                <pv:EntityId>EnityId of Merchant</pv:EntityId>
                <pv:LocationId>LocationId of the transaction</pv:LocationId>
                <pv:PaymentOrigin>Internet</pv:PaymentOrigin>
                <pv:AccountType>Visa</pv:AccountType>
                <pv:OperationType>Sale</pv:OperationType>
                <pv:SettlementType>Card_Transfer</pv:SettlementType>
                <pv:EffectiveDate>2022-02-21</pv:EffectiveDate>
                <pv:Description>cardexample</pv:Description>
                <pv:TotalAmount>25.00</pv:TotalAmount>
                <pv:TerminalNumber>__WebService</pv:TerminalNumber>
                <pv:TransactionNumber>test1234</pv:TransactionNumber>
                <pv:Field1>A1234</pv:Field1>
                <pv:Field2></pv:Field2>
                <pv:Field3></pv:Field3>
                <pv:AccountNumber>4111111111111111</pv:AccountNumber>
                <pv:CardExpiresMonth>04</pv:CardExpiresMonth>
                <pv:CardExpiresYear>2022</pv:CardExpiresYear>
                <pv:CVVNumber>3123</pv:CVVNumber>
                <pv:IsBusinessPayment>0</pv:IsBusinessPayment>
                <pv:NameOnAccount>Test User</pv:NameOnAccount>
                <pv:BillingAddress1>1234 Avenue</pv:BillingAddress1>
                <pv:BillingCity>Allen</pv:BillingCity>
                <pv:BillingStateRegion>TX</pv:BillingStateRegion>
                <pv:BillingPostalCode>75050</pv:BillingPostalCode>
                <pv:BillingCountry>US</pv:BillingCountry>
                <pv:NotificationMethod>Email</pv:NotificationMethod>
                <pv:FaceFeeType>Face</pv:FaceFeeType>
            </pv:transaction>
            <pv:ownerApplication>Web_Service</pv:ownerApplication>
        </pv:AuthorizeTransaction>
    </soap:Body>
</soap:Envelope>
  • Step 3 Once this request is sent to the endpoint, we should get a successful response and there are a few key items that are important to log with this response.
    • ReferenceNumber - EPS generates this value for you to use for pulling reporting information on the transaction later. You will want to store this number with the transaction in your database.
    • Success - indicates a successful transaction.
    • Error - indicates if an error has occurred.
    • ResponseCode - EPS code signifying result of the request.
    • ActualDate - when the transaction was created in EPS.
    • ResponseMessage - detailed description for the response code when applicable.

Here is what our successful response looks like for this example.

</soap:Envelope><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
        <AuthorizeTransactionResponse xmlns="https://ssl.selectpayment.com/PV">
            <AuthorizeTransactionResult>
                <ReferenceNumber>T:478D3MHNLA1</ReferenceNumber>
                <Success>true</Success>
                <Error>false</Error>
                <ResponseCode>Success</ResponseCode>
                <ActualDate>2022-02-21T00:00:00-06:00</ActualDate>
                <ResponseMessage>Success</ResponseMessage>
                <OriginatedAs>Card_Transfer</OriginatedAs>
            </AuthorizeTransactionResult>
        </AuthorizeTransactionResponse>
    </soap:Body>
</soap:Envelope>

Here is how the single payment example looks represented as a complete workflow diagram. Click on the method boxes to be taken to the specific API reference.

Integrator Payment Flow
EPS Web Service Flow

EPS Web Service

1.

Gather payment information from user online.

2.

Initiate the payment with AuthorizeTransaction using payment information gathered from user.

Successful payment Key Data Elements: AuthorizeTransactionResponse

  • ReferenceNumber = Unique number assigned to transaction by EPS
  • Success = true
  • Error = false
  • ResponseCode = Success
  • ResponseMessage = Additional information for response code if applicable
3.

For successful payments:

  • store the ReferenceNumber along with your TransactionNumber from AuthorizeTransaction in your database
  • display and log any results.

Unsuccessful Payment Key Data Elements: AuthorizeTransactionResponse

  • Success = false
  • Error = true or false
  • ResponseCode = See API Reference
  • ResponseMessage = Additional information for response code if applicable
4

For Unsuccessful payments:

  • display and log the error and responsecode as needed
 

 

Handling Errors and Failed Requests​

Not all requests will be successful, so we will need to run through a few common errors you should be ready to handle.

  • Duplicate transaction - Duplicate transactions will be declined. Transactions are checked against our duplicate table which is a rolling 75 days of history and is checked against other transactions for the same merchant (entityID). It is important that transactions that receive a duplicate error are not automatically retried and there are two ways to handle it.
    • The transaction is a true duplicate and will not need another attempt. Record the response and no further action is needed.
    • You are certain that the transaction is not really a duplicate and need it to process. For WEB payments a duplicate is flagged when the Transaction Number is not unique. This means the Transaction Number value will need to change to something unique and resubmit the request.
  • Timeout waiting for response - Systems should be designed to wait 10 seconds for Card transactions to receive a response before timing out. If a timeout occurs, you can attempt to query the system with one of the GetTransaction methods to verify if the transaction was received. If it was not the transaction can be resubmitted.

Next steps​

  • Customize the workflows to fit your specific business needs. You can apply the principles shown in these examples and customize the requests using the API Reference to suit your needs.

  • Review the API Reference This guide is just a starting point to show a common use case scenario for making internet payments. Please review the API Reference to see all APIs and their technical specifications.

  • Explore other guides We have other guides to show how to leverage our APIs in other common use cases so if this one doesn't cover what you are looking for, give another guide a try.

  • Get certified and move into production Ready to put your new code into production use? Refer to this process guide that explains our certification steps and how to contact us to get started.