On This Page

PayTo Pay by Bank Developer Guide

This section describes how to use this guide and where to find further information.
Audience and Purpose
This guide is intended for merchant developers who want to offer the PayTo Pay by Bank payment option in their online stores.
Conventions
This special statement appears in this document:
IMPORTANT
An
Important
 statement contains information essential to successfully completing a task or learning a concept.
Customer Support
For support information about any service, visit the Support Center:

Recent Revisions to This Document

25.11.01

Pilot release.

Introduction to PayTo Pay by Bank

Cybersource
 offers PayTo Pay by Bank, a payment method that enables your e-commerce customers to pay directly from their bank accounts. When using PayTo, your customers do not need to enter their card information. After you integrate PayTo into your checkout experience, your customers select the
Pay by Bank
 option. This checkout option enables your customers to choose their bank from a list of trusted partner banks to authorize the payment. After payment approval, the funds transfer from your customer's account to your merchant account. This payment method is an account-to-account (A2A) transfer.

Benefits of Using PayTo Pay by Bank

PayTo provides these benefits for e-commerce payments:
  • Immediately transfers funds from the customer's account to your merchant bank account.
  • Reduces the amount of customer data you store.
  • Using a customer's bank authentication network to securely process payments.
  • Avoids card processing fees.

Supported Country and Currency

PayTo is available in Australia and supports payments using the Australian dollar (AUD).

Supported Services

Sale, refund, and check status services are available with PayTo Pay by Bank. For more information, see these sections:
You can also subscribe to webhook notifications. With webhook subscriptions,
Cybersource
 will automatically notify you when a sale or a refund is completed. See Introduction to Webhooks.

Getting Started with REST

To process payments through
Cybersource
, set up your payment processing system to be REST compliant.
Cybersource
 uses the REST architecture for developing web services. REST enables communication between a client and server using HTTP protocols.
If you have not set up secure communications between your client and server using either a JSON Web Token or HTTP signature, see the .

How to Process a Payment

This workflow illustrates a successful payment using PayTo Pay by Bank.

Figure:

Processing a Payment
  1. The customer begins to check out on your website and chooses the PayTo Pay by Bank payment option. This option enables the customer to choose their bank from a list of available partner banks.
  2. You send a sale request to
    Cybersource
    . For more information, see Process a Sale.
  3. Cybersource
     responds with a
    PENDING
     status, sale request ID, and the PayTo redirect URL.
  4. You redirect the customer to the PayTo URL.
  5. The customer uses their bank account or PayID to approve the payment and is redirected to your website.
  6. Cybersource
     sends you an automatic SETTLED or FUNDED webhook notification when the sale is complete. For more information, see Introduction to Webhooks.
  7. If you do not receive a webhook notification or have not enabled webhook notifications, you send periodic check status requests with the sale request ID to
    Cybersource
     until you receive an updated status. For more information, see Check a Status.
  8. Cybersource
     responds to your check status request with a SETTLED or FUNDED status. This status confirms that the payment is complete.
  9. You confirm the payment.

Refund Workflow

This workflow describes the sequence of events that comprises a successful PayTo Pay by Bank refund.

Figure:

Issuing a Refund Workflow

Figure:

  1. The customer returns the purchase to the merchant.
  2. The merchant sends a refund API request to
    Cybersource
     with the request ID from the successful capture. For more information, see Refund a Payment.
  3. Cybersource
     responds to the merchant with the
    PENDING
     status and a refund request ID.
  4. The merchant sends periodic check status API requests to
    Cybersource
     until the status updates. For more information, see Check a Status.
  5. Cybersource
     responds to the merchant with the
    REFUNDED
     status when the refund is processed.
  6. The merchant displays a refund confirmation to the customer.

Check Transaction Status Workflow

This workflow describes the sequence of possible statuses you can receive when processing a PayTo Pay by Bank transaction.

Figure:

Transaction Statuses Workflow
  1. The merchant sends a check status API request to
    Cybersource
     to verify the status of the sale and receives one of these statuses:
    • FAILED
      : The sale request failed. A failed request can be due to either Pay by Bank rejecting the transaction or due to a technical error.
    • FUNDED
      : The sale request is funded for the requested amount.
    • PENDING
      : The sale request is accepted but is not complete. Request the check status service to retrieve status updates.
    • SETTLED
      : The sale request is settled for the requested amount.
  2. The merchant sends a check status API request to
    Cybersource
     to verify the refund status and receives one of these statuses:
    • FAILED
      : The refund request failed. A failed request can be due to PayTo Pay by Bank rejecting the transaction or due to a technical error.
    • PENDING
      : The sale request is accepted but is not complete. Request the check status service to retrieve status updates.
    • REFUNDED
      : The settled amount is successfully refunded.

Transaction Processing

This section describes how to process transactions using the
REST API
.

Process a Sale

This section describes how to send a sale request to process a payment.
A sale request authorizes and captures a payment in the same request. A successful sale response includes a redirect URL and a
PENDING
 status. Redirect the customer to the PayTo URL to allow the customer to complete the checkout using their bank information. When the customer completes the checkout, the customer is redirected to your website.
When you receive a successful response, save the sale request ID in the
id
 response field to perform a follow-on check status request or refund request.

Calculating the Grand Total

Include the grand total in the request by using the
orderInformation.amountDetails.totalAmount
 field.

Endpoints

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

Processing a Sale

Processing a sale requires you to use information from the API response message to redirect the customer to a website where the customer can complete the checkout. Follow these steps to process a sale.
  1. Send a POST request to the
    https://api.cybersource.com
    /pts/v2/payments
     endpoint and include these required fields:

    ADDITIONAL INFORMATION

    Set to an 18-character value or less.
    Set to
    AUD
    .
    orderInformation.invoiceDetails.productDescription
    Set to
    payToPayByBank
    .
    Set to
    bankTransfer
    .
    Set to
    AP_SALE
    .
  2. If needed, include any of these optional line item fields in the request:

    ADDITIONAL INFORMATION

  3. Redirect the customer to the URL in the
    processorInformation.paymentUrl
     response field.
    "paymentUrl": "https://checkout.banked.com/au/3645bd90-7625-4202-8cc3-a1cb58358899?token=eyJhbGciOiJI"
  4. Save the request ID in the
    id
     field from the sale response. Include the request ID in a check status request to confirm that the payment is complete.
    "id": "7544094135706957804805"

AFTER COMPLETING THE TASK

When the sale amount is successfully processed,
Cybersource
 sends a
SETTLED
 webhook notification. See Introduction to Webhooks. If you do not receive a webhook notification, send a check status request. See Check a Status.

Example: Processing a Sale

Request
{
    "clientReferenceInformation": {
        "code": "TC84100-1"
    },
    "processingInformation": {
        "actionList": [
            "AP_SALE"
        ]
    },
    "orderInformation": {
        "invoiceDetails": {
            "productDescription": "test description"
        },
        "amountDetails": {
            "totalAmount": "1999.99",
            "currency": "AUD"
        }
    },
    "paymentInformation": {
        "paymentType": {
            "name": "bankTransfer",
            "method": {
                "name": "payToPayByBank"
            }
        }
    }
}
Response to a Successful Request
{
    "orderInformation": {
        "amountDetails": {
            "totalAmount": "1999.99",
            "currency": "AUD"
        }
    },
    "processorInformation": {
        "transactionId": "3645bd90-7625-4202-8cc3-a1cb58358899",
        "paymentUrl": "https://checkout.banked.com/au/3645bd90-7625-4202-8cc3-a1cb58358899?token=eyJhbGciOiJI",
        "responseCode": "00001",
        "completeUrl": "merchant_success_url.com"
    },
    "message": "Request was processed successfully.",
    "clientReferenceInformation": {
        "code": "TC84100-1"
    },
    "reconciliationId": "KOZX0DMQKX0A",
    "status": "PENDING",
    "id": "7544094135706957804805",
    "submitTimeUtc": "2025-08-05T15:56:53Z"
}

Refund a Payment

Request a refund to return the funds from a completed payment. Refunding a payment requires the transaction ID from a capture or sale response.

Supported Refund Services

These refund services are available with PayTo Pay by Bank:
  • Full refunds for the same amount of the original sale
  • Partial refunds for an amount less than the original sale

Endpoints

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

Required Fields for Refunding a Payment

Example: Refunding a Payment

Request
{
  "paymentInformation": {
    "paymentType": {
      "name": "bankTransfer",
      "method": {
        "name": "payToPayByBank"
      }
    }
  },
  "processingInformation": {
    "actionList": ["AP_REFUND"]
  },
  "orderInformation": {
    "amountDetails": {
      "totalAmount": "100.00",
      "currency": "AUD"
    }
  }
}
Response to a Successful Request
{
    "processorInformation": {
        "responseCode": "00001",
        "transactionId": "9af6bd29-8ea9-4f30-b6d4-58313566bcb0"
    },
    "orderInformation": {
        "amountDetails": {
            "totalAmount": "100.00",
            "currency": "AUD"
        }
    },
    "reconciliationId": "KOZX0DMQKX0D",
    "message": "Request was processed successfully.",
    "status": "PENDING",
    "id": "7544094135706957804805",
    "submitTimeUtc": "2025-08-05T17:52:08Z"
}

Check a Status

Request a check status to retrieve the current status of a transaction request. The check status request is helpful when know when a pending status updates. The check status request requires the request ID from the response of the corresponding request you are attempting to retrieve.

Endpoints

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

Response Statuses

If you send a check status request to retrieve the current sale status, these are the possible responses:
  • FAILED
    : The sale request failed. A failed request can be due to either Pay by Bank rejecting the transaction or due to a technical error.
  • FUNDED
    : The sale request is funded for the requested amount.
  • PENDING
    : The sale request is accepted but is not complete. Request the check status service to retrieve status updates.
  • SETTLED
    : The sale request is settled for the requested amount.
If you send a check status request to retrieve the current refund status, these are the possible responses:
  • FAILED
    : The refund request failed. A failed request can be due to PayTo Pay by Bank rejecting the transaction or due to a technical error.
  • PENDING
    : The sale request is accepted but is not complete. Request the check status service to retrieve status updates.
  • REFUNDED
    : The settled amount is successfully refunded.

Required Fields for Checking a Status

Set to an 18-character value or less.
Set to
payToPayByBank
.
Set to
bankTransfer
.
Set to
AP_STATUS
.

Example: Checking a Status

Request
{
  "paymentInformation": {
    "paymentType": {
      "name": "bankTransfer",
      "method": {
        "name": "payToPayByBank"
      }
    }
  },
  "processingInformation": {
    "actionList": ["AP_STATUS"]
  }
}
Response to a Successful Request
{
    "processorInformation": {
        "responseCode": "00005"
    },
    "reconciliationId": "KOZX0DMQKX0C",
    "message": "Request was processed successfully.",
    "status": "FUNDED",
    "id": "7544157383456089204805",
    "submitTimeUtc": "2025-08-05T17:42:18Z"
}

Introduction to Webhooks

Webhooks are automated notifications generated by system events that occur in your organizations. You can create a webhook subscription and designate a URL to receive notifications when a sale status updates. By setting up automatic webhook notifications, you do not need to send check status requests to monitor a sale status.
Webhook notifications are only sent when a sale status changes.
IMPORTANT
This section only describes overview information about creating a webhook subscription. You must complete additional set-up tasks that are not described in this guide before you can create a webhook subscription. If you have not set up your system to support webhooks, see the
Webhooks Implementation Guide for the REST API
.
Notifications that contain sensitive, personally identifiable information (PII), such as account numbers, are sent using message-level encryption.
Transport Layer Security is required in order to ensure data integrity.

Endpoints

Send a POST request to one of these endpoints:
  • Test:
    POST
    https://apitest.cybersource.com
    /notification-subscriptions/v2/webhooks
  • Production:
    POST
    https://api.cybersource.com
    /notification-subscriptions/v2/webhooks
  • India Production:
    POST https://api.in.cybersource.com/notification-subscriptions/v2/webhooks

Notification Statuses

Webhook subscriptions send these notification statuses:
  • CANCELLED
    : The customer did not complete the checkout using the redirect URL.
  • FAILED
    : The sale request failed.
  • SETTLE_INITIATED
    : The customer completed checkout and PayTo Pay by Bank is processing the sale.
  • SETTLED
    : The sale is settled for the requested amount.

Test Your Webhook Requests

You can use the
Cybersource
 REST API Reference
 to send webhook related test requests. See the Create a Webhook section in the
Cybersource
 REST API Reference
.

Required Fields for Webhooks

name
organizationId
eventTypes
Set the value of this field to
payments.payments.updated
.
productId
Set the value of this field to
alternativePaymentMethods
.
securityPolicy.securityType
Set to
KEY
.
webhookUrl

Optional Fields for Webhooks

deactivateflag
Required if the
healthCheckUrl
 field is present.
Set to
true
 to automatically activate the subscription.
healthCheckUrl
Set to the health check URL. Required to auto-activate the subscription. If you do not include this field, the created subscription is inactive. An inactive subscription does not send notifications.
retryPolicy.deactivateFlag
retryPolicy.firstRetry
retryPolicy.interval
retryPolicy.numberOfRetries
retryPolicy.repeatSequenceCount
retryPolicy.repeatSequenceWaitTime

Example: Webhooks

Request
{
    "name": "My Custom Webhook",
    "description": "Sample Webhook from Developer Center",
    "organizationId": "paytotestapm003",
    "productId": "alternativePaymentMethods",
    "eventTypes": [
        "payments.payments.updated"
    ],
    "webhookUrl": "https://MyWebhookServer.com:8443/simulateClient",
    "notificationScope": "SELF",
    "securityPolicy": {
        "securityType": "KEY",
        "proxyType": "external"
    }
}
Response to a Successful Request
{
  "organizationId": "paytotestapm003",
  "productId": "alternativePaymentMethods",
  "eventTypes": [
    "terminalManagement.assignment.update"
  ],
  "webhookId": "ddb9bced-c3e3-1b1d-e053-9c588e0a3c42",
  "name": "My Custom Webhook",
  "webhookUrl": "https://MyWebhookServer.com:443/simulateClient",
  "healthCheckUrl": "https://MyWebhookServer.com:443/simulateClientHealthCheck",
  "createdOn": "2022-04-28T15:39:56.928Z",
  "status": "ACTIVE",
  "description": "Sample Webhook from Developer Center",
  "securityPolicy": {
    "securityType": "KEY",
    "digitalSignatureEnabled": "yes"
  },
  "version": "3",
  "notificationScope": "SELF"
}

Reference Information

This section contains reference information that is useful when integrating PayTo Pay by Bank.

Including Line Items in Requests

Unique item in your customers' purchases can be itemized as line items when you create or manage an order.
Line items
 are used to include information about each item, such as product name, quantity, and price.
Line items are included in a request in the
lineItem[]
 array request field.
These fields are required for each line item in your request:
Including Line Items
This example shows how to format line items in a request.
{
 "orderInformation": {
        "lineItems": [
            {
                "productName": "test-product-1",
                "quantity": 5,
                "productDescription": "description-123",
                "unitPrice": "20",
                "taxAmount": "10",
                "totalAmount": "100",
                "typeOfSupply": "01"
            },
            {
                "productName": "test-product-2",
                "quantity": 1,
                "productDescription": "description-456",
                "unitPrice": "5",
                "taxAmount": "1",
                "totalAmount": "6",
                "typeOfSupply": "01"
            },
            {
                "productName": "test-product-3",
                "quantity": 2,
                "productDescription": "description-789",
                "unitPrice": "4",
                "taxAmount": "2",
                "totalAmount": "10",
                "typeOfSupply": "01"
            }
        ]
    }
}

Generating Reports In the
Business Center

You can generate various types of reports for your financial and reconciliation data. For more information about how to automate your reports, see the
Reporting Developer Guide
. For more information about how to use your
Business Center
 account to generate reports, see the
Reporting User Guide
.
The
Reporting User Guide
 contains these relevant topics:
  • How and When Reports Are Generated
  • Downloading Available Reports
  • Subscribing to Standard Reports

Additional Resources

For additional information about how to use the
Business Center
 and manage reports, see these helpful resources.
Business Center
 Navigation
For an overview of the various resources available in the
Business Center
, see this YouTube video:
Getting Started with the
Business Center
For a step-by-step demonstration of how to navigate in the
Business Center
, see this YouTube video:
Managing Report Subscriptions
For an overview of how to manage report subscriptions in the Downloadable Reports section in the
Business Center
, see this YouTube video:
Downloading Reports
For an overview of how to download available reports in the Reports section of the
Business Center
, see this YouTube video:

Configure Alternative Payments Methods
in the
Business Center

Follow these steps to configure alternative payment methods
in the
Business Center
:
  1. In the left navigation panel, click the
    Available Products
     icon. The Available Products page appears.
  2. In the Alternative Payment Methods section, click
    Enable
    .
  3. Check the box next to each alternative payment method you want to enable and configure. You can choose alternative payment methods from these categories:
    • Bank Transfer
    • Buy Now Pay Later (BNPL)
    • Card Payment
    • Direct Debit
    • eWallet
    • Gift Card
    • Local Card
    • Post Pay Reference
    • QR
  4. Click
    Continue
    . The Product Configuration page appears.
  5. Enter the required details for each alternative payment method you want to configure.
    Click
    Copy to other sections
     to populate the information to any other alternative payment methods that you selected.
    IMPORTANT
    You must select
    I have read and agree to the Terms and Conditions
     for each alternative payment method you want to enable.
  6. Click
    Continue
     to return to the Available Products page.

Configure the Transacting Organization and Products

Follow these steps to modify the transacting organization details, or to enable and configure products for the transacting organization:
  1. Click
    Start
     in the Transacting Organization and Products section. The Transacting Organization and Products page is displayed.
  2. Optional: modify the name and ID of the organization by using the text fields in the Transacting Organization Details section. By default, the name is the merchant name with 001 added to the end of the name. If you accept this default, additional transacting organizations will have default names that iterate the numbers at the end of their names, beginning with 002.
  3. Optional: to edit the organization information, Click
    Edit
     in the Transacting Organization Information section. After editing, click
    Apply
    .
  4. To enable a product in the Product Enablement section, click the Enablement drop-down menu and select
    Enabled
    .
  5. To modify the configuration, click the
    Edit
     or
    configure
     button (depending on the product). Some products are not configurable.
  6. To confirm the configuration, click
    Apply
    .
  7. To save all product configurations, click
    Save
    . You are returned to the Add Merchant page.
  8. To continue working with this organization, click
    Continue working with this merchant
    . To finish and return to Merchant Management, click
    Return to merchant management
    .

Webhook Subscriptions

Webhooks are automated notifications generated by system events that occur in your organization. You can enroll in a sale or refund event and designate a URL to receive notifications when the event updates. You set up your webhook subscriptions only once.
Notifications that contain sensitive, personally identifiable information such as account numbers are sent using message-level encryption.
Transport Layer Security is required in order to ensure data integrity.

Endpoints

  • Production
    :
    https://api.cybersource.com
    /notification-subscriptions/v2/webhooks
  • Test
    :
    https://apitest.cybersource.com
    /notification-subscriptions/v1/webhooks

Notification Statuses

Webhook subscriptions send these status notifications:
  • ABANDONED
    : The customer did not complete the transaction.
  • CANCELLED
    : The customer did not complete the checkout using the redirect URL.
  • COMPLETED
    : The transaction is complete.
  • FAILED
    : The payment failed.
  • PENDING
    : The payment was initiated.
  • REFUNDED
    : The settled amount is successfully refunded.
  • SETTLED
    : The sale request is settled for the requested amount.

Additional Requirements

Webhooks Implementation Guide
There are additional requirements for implementing webhooks that are not discussed in this guide. For more information, see the for the REST API.
Create New Webhooks
To create an alternative payment notification webhook, see the Create a Webhook section in the
Cybersource
 REST API Reference
.

Webhook Health Check URL and Automatic Revalidation

When you create a webhook subscription,
Cybersource
 recommends that you include a health check URL in the request. Including a health check URL enables
Cybersource
 to monitor your server's status for reliability. When
Cybersource
 detects that your health check URL is unresponsive, notification deliveries are withheld until your health check URL becomes responsive again. A health check URL ensures that you do not miss any notifications.
To add a health check URL to your
create a subscription
 request, include the
healthCheckurl
 field and set it to your health check URL. You must also include the
deactivateflag
 field and set it to
true
 to enable
Cybersource
 to withhold notifications for periods when your server becomes unresponsive.

Automatic Activation

After you successfully create or update a subscription,
Cybersource
 pings your health check URL within 5—10 minutes. If
Cybersource
 receives a response, the subscription status automatically becomes
ACTIVE
 and notifications are delivered. When
Cybersource
 does not receive a response, your subscription status remains
SUSPENDED
 until
Cybersource
 receives a response. If you did not include a health check URL when you created the subscription,
Cybersource
 pings your webhook URL for automatic activation instead. You can also activate a subscription that is not automatically activated by sending a PUT request. For more information, see Activate a Webhook Subscription.

Figure:

Webhook Automatic Activation

Automatic Revalidation

After the subscription's initial activation,
Cybersource
 continues to monitor your server status. If
Cybersource
 detects that your server is unavailable, your subscription status automatically updates to
SUSPENDED
, and notifications are withheld. When
Cybersource
 detects that your server is available again, your subscription status automatically updates to
ACTIVE
, and all withheld notifications are delivered.

Reason Codes and Pay by Bank Response Codes

This table describes some of the reason codes and Pay by Bank response codes that you receive when you request a Pay by Bank service. Use the values listed in the table to determine the transaction result.
For additional reason codes and descriptions, see the
Cybersource
 Reason Codes with REST API response
 article in the
Cybersource
 Developer Center.
Reason Codes and Pay by Bank Response Codes
Reason Code
Pay by Bank Response Code
Description
100
  • 00000
    : Completed status
  • 00001
    : Pending status
  • 00002
    : Abandoned status
  • 00003
    : Authorized status
  • 00004
    : Settled status
  • 00006
    : Refunded status
Successful transaction.
102
  • 10000
    : Failed status
One or more fields in the request contain invalid data.
150
  • 20000
    : Failed status
  • 20001
    : Failed status
  • 20002
    : Failed status
Possible reasons:
  • The signature was not included in the HTTP header.
  • The signature in the HTTP header has expired, or it is not a valid signature.
203
  • 30000
    : Failed status
  • 30100
    : Failed status
  • 30200
    : Failed status
  • 30400
    : Failed status
  • 30500
    : Failed status
Pay by Bank declined the transaction because of funding source problems, or the transaction was flagged as high risk.
204
  • 30350
    : Failed status
Payment declined because of insufficient funds in the account.
233
  • 30600
    : Failed status
  • 30700
    : Failed status
Pay by Bank declined the transaction because of tax errors or government compliance errors.

Add Merchant Account Information

Follow these steps to add merchant account information:
  1. In Basic Information, enter the merchant account name and the organization ID in the provided text fields.

    ADDITIONAL INFORMATION

    • The merchant account name is the name of the business.
    • The organization ID is the name or identifier of the account that you are creating. It must be unique, not just in the portfolio or account, but in the system.
  2. Enter the merchant information in the provided text fields. Required fields are noted with an asterisk (*).
  3. Click
    Save
    . You are returned to the Add Merchant page. You can skip the optional hierarchy step by clicking
    Skip
    .

Set Up the Transacting Organization and Products

The transacting organization is the entity that processes transactions. Follow these steps to create a transacting organization and configure products for it:
  1. Click
    Start
     in the Transacting Organization and Products section. The Transacting Organization and Products page is displayed.
  2. Optional: modify the name and ID of the organization by using the text fields in the Transacting Organization Details section. The ID must be unique, not just in the portfolio or account, but across the system. By default, the name is the merchant name with 001 added to the end of the name. If you accept this default, additional transacting organizations will have default names that iterate the numbers at the end of their names, beginning with 002.
  3. Optional: By default, the organization information is inherited from the parent organization. To edit the organization information, click
    Edit
     in the Transacting Organization Information section. After editing, click
    Apply
    .
  4. To enable a product in the Product Enablement section, click the Enablement drop-down menu and select
    Enabled
    .
  5. To modify the configuration, click the
    Edit
     or
    Configure
     button (depending on the product). Some products are not configurable.
  6. To confirm the configuration, click
    Apply
    .
  7. To save all product configurations, click
    Save
    . You are returned to the Add Merchant page.
  8. To continue working with this organization, click
    Continue working with this merchant
    . To finish and return to Merchant Management or to add another merchant, click
    Return to merchant management
    .

    ADDITIONAL INFORMATION

    The image below shows the Transacting Organization and Products page.

    Figure:

    Transacting Organization and Products

Configure the Retry Policy

If your webhook URL or health check URL are unresponsive,
Cybersource
 resends the webhook notifications according to the subscription's
retry policy
. All subscriptions are created with a default retry policy. You can configure the default retry policy when you create a subscription or update the webhook subscription.
To configure a subscription's retry policy, include these required fields in the
create a subscription
 request or an
update a subscription
 request:
retryPolicy.deactivateFlag
Set to one of these possible values:
  • false
    : Notifications are
    not
     withheld when your webhook URL or health check URL are unresponsive. This is the default value.
  • true
    : Notifications are withheld when your webhook URL or health check URL are unresponsive, and the subscription status updates to
    SUSPENDED
    . When the URLs become responsive again, the withheld notifications are sent and the subscription status updates to
    ACTIVE
    .
retryPolicy.firstRetry
The number of minutes before the notification is resent. The default value is
1
.
retryPolicy.interval
The number of minutes between each retry attempt. The default value is
1
.
retryPolicy.numberOfRetries
The number of retry attempts. The default value is
3
.
retryPolicy.repeatSequenceCount
The number of times to repeat the retry sequence. The default value is
0
.
retryPolicy.repeatSequenceWaitTime
The number of minutes between each repeat sequence. The default value is
0
.

Check Status

Send a check status request to retrieve status updates for either a pending sale or refund. A check status request requires the request ID from the sale response or the refund response, which is the
id
 field value.
Cybersource
 recommends using the check status service only when you do not receive a webhook notification. To set up a webhook subscription, see Webhook Subscriptions.

Endpoints

Production:
POST
https://api.cybersource.com
/pts/v2/refresh-payment-status/
{id}
Test:
POST
https://apitest.cybersource.com
/pts/v2/refresh-payment-status/
{id}
Set the
{id}
 to the request ID of the API service you are retrieving.

Response Statuses

Cybersource
 responds to your check sale status request with one of these statuses in the
status
 field:
Check Status for a Sale
  • ABANDONED
    : The customer did not complete checkout within the allotted time, and the redirect URL has expired.
  • COMPLETED
    : The customer completed the checkout process.
  • PENDING
    : The sale request is accepted but is not complete. Request the check status service to retrieve status updates.
  • REJECT
    : The sale request failed. A failed request can be due to either Pay by Bank rejecting the transaction or due to a technical error.
  • SETTLED
    : The sale request is settled for the requested amount.
Check Status for a Refund
  • PENDING
    : The refund request is accepted but is not complete. Request the check status service to retrieve status updates.
  • REFUNDED
    : The settled amount is successfully refunded.
  • REJECT
    : The refund request failed. A failed request can be due to either Pay by Bank rejecting the transaction or due to a technical error.
The check status service also responds with a reason code in the
processorInformation.responseCode
 field. For more information about reason codes, see Reason Codes and Pay by Bank Response Codes.

Manage Webhook Subscriptions Requests

This section describes how to manage your webhook subscriptions using the REST API. These follow-on requests require the webhook subscription ID.
After you set up a webhook subscription, you can manage your subscription using these requests:
  • Retrieve the details of a subscription
  • Retrieve a list of subscriptions by product and event
  • Update a subscription
  • Delete a subscription
  • Verify a subscription's configuration
  • Activate a subscription
  • Deactivate a subscription

Activate a Webhook Subscription

This section describes how to activate a webhook subscription.
This request requires the webhook subscription ID. The subscription ID is in the
webhookId
 response field from the
create a webhook subscription
 request.

Endpoints

Send a PUT request to one of these endpoints. The
{webhookId}
 is the webhook subscription ID.
  • Test:
    PUT
    apitest.cybersource.com
    /notification-subscriptions/v2/webhooks/
    {webhookId}
    /status
  • Production:
    PUT
    api.cybersource.com
    /notification-subscriptions/v2/webhooks/
    {webhookId}
    /status
  • India Production:
    PUT https://api.in.cybersource.com/notification-subscriptions/v2/webhooks/
    {webhookId}
    /status