The monthly detailed transaction reports contain records of the original transaction, as well as the refunds. The refund records contain the transaction ID of the original transaction, so that the purchase and refund can be easily correlated.
The Payment API is designed to protect the consumer's identifying information. Transactions and subscriptions have a ConsumerId value, but that value is a random key that may not be persistent.
This is required when creating a new subscription and must be a unique string. The XML status response for a subscription will contain this value with the name, merchantSubscriptionId. It is required for the Subscription Details request. We recommend that you use the same value as the MerchantTransactionId.
Sales conversion rates are driven by a number of factors, such as the product itself, the quality, the promotion, and the friction encountered in the purchase process. Payment API can provide a simple, low-friction payment process that can make it easy for your prospective customer to be converted in to a sale.
The Payment API can support sales of digital and virtual goods and in-app billing, including one-time and subscription purchases, via any internet-connected device.
Settlement is supported with a simple invoice presentation that includes enough details for developers to understand the sales and costs of apps. Appropriate contact information is provided in case customers have disputes or questions. The system also provides revenue assurance, which includes details on collections, refunds, suspensions, and terminations.
The Payment API provides the functionality to handle the authentication, capture use consent, confirmation, and invoice posting process for a purchase, so that you don't have to develop these functionalities yourself. Payment API gives you the control and flexibility to manipulate the look and feel of how you present your customers with purchase options, as well as how you deliver digital goods to your customers.
IsPurchaseOnNoActiveSubscriptionmust be set to "false"
- Category 2, Virtual Goods, is not allowed for Subscriptions
SubscriptionRecurringNumbermust be set to "99999"
MerchantTransactionIdmust be unique
MerchantSubscriptionIdListmust be a single value, and that must be unique
SubscriptionRecurringPeriodmust be "MONTHLY"
SubscriptionRecurringPeriodAmountmust be "1"
- Subscriptions continue indefinitely until cancelled.
- Merchants may cancel subscriptions through the Refund API
- Customers may cancel subscriptions through the Online Assistance Center
- Customer Service Representatives may cancel subscriptions through the Customer Care Center
The following precautions must be observed in the handling your production client secret:
- The client secret shall only be distributed to authorized and trusted personnel.
- The client secret shall be stored on a secure server that is:
- Free from computer viruses and unauthorized software.
- Only accessible by authorized personnel and software.
- The client secret is only intended to be used in a server-to-server API request via HTTPS, (e.g. the Access Token resource and Notary service) and should not be transmitted or shared with client-facing applications.
- If unauthorized access of the client secret is detected, then the client secret must be changed immediately.
We provide a suite of reporting capabilities, including transaction-level details, summary reports, and settlement reports to help you manage your business.
Detailed reports can be requested by Submit a Ticket.
There are no limits to the number of refunds that a merchant can issue by using the Refund Transaction method. However, if a customer claims five (5) refunds within a 90* day period through the AT&T Wireless customer care center, then that customer is placed on a Highly Refunded Activity (HRA) purchase blocker list which will suspend the purchase eligibility of the customer for 180 days.
*Configurable AT&T parameters (subject to updates).
There are three ways to initiate a refund:
- A merchant-initiated refund using the AT&T API Platform Payment API
- A customer-initiated refund through the Online Assistance Center
- An AT&T Customer Service Representative-initiated refund through the Customer Care Center
Merchant-initiated refunds cancel the subscription immediately and stop the most recent payment. Customer Service Representatives have these options:
- Cancel the subscription immediately and refund the full amount
- Put the subscription in the "Do Not Renew" state which prevents the next payment transaction from happening.
This information needs to be stored by the developer application during the transaction/subscription creation time.
The Merchant ID is a unique identifier that identifies each merchant in the backend systems.
Since there are no email notifications for payment transaction activity, the Developer App should register to receive notification callbacks and implement the actions for the various events that it will receive.
These fields need to be known by the Merchant Application based on the API call that was made for creating this subscription. Other ways to know about these fields is through Reports.
No. With this release, the lowest value that you can use to make a transaction is $0.01.
Payment Notification supports the following business scenarios:
- New Transaction/New Subscription—When the consumer successfully completes a purchase (one time/subscription). Payment API generates a grant event.
- Subscription renewal—When a consumer’s subscription is successfully renewed at the end of their current subscription period, API platform generates a renew event.
- Request a DNR—When the consumer requests to discontinue a subscription offer, the consumer’s access to the content is maintained until the subscription period ends, which is typically the end of a 30-day period. Platform generates a conclude event.
- Renewal processing failure—Subscriptions are automatically discontinued if a renewal cannot be processed successfully a conclude event is generated.
- Request cancellation of a subscription offer—When the consumer receives a refund for the current subscription period via the AT&T Online Assistance Center, through an AT&T CSR or via the Refund Transaction method. API platform generates a revoke event.
- Request a refund—When the consumer requests a refund for a single-item offer or subscription offer, API platform generates a revoke event.
To use Payment applications you must have a Merchant Account. Please contact your Organization Profile Administrator to determine if you have a Merchant Account. If you do not, then the Organizational Profile Administrator must create a merchant account by selecting "Manage My Account" and then select "Setup Merchant Account".
After the merchant account is set up you will receive an email from AT&T Developer Program with the subject, "Notice from AT&T: Merchant Account Setup", that contains a "Merchant ID". This "Merchant ID" value must be placed in the Merchant ID field while creating an application.
MSISDN is consumer sensitive information and should be used by the merchant for any reconciliation with respect to the Payment API transactions. It should not be used for any other purpose.
The developer or content owner is primarily responsible for addressing subscriber issues associated with the application or content being sold. AT&T Customer Care is the final serving contact and escalation point.
Following methods are available for developers to implement in their applications:
- New Subscription
- New Transaction
- Payment Notification
- Refund Transaction
Contact the AT&T Developer Support Program for details about Payment API methods.
Go to developer.att.com, sign up, accept the Terms and Conditions to gain access to our suite of Payment APIs, and finally, establish a merchant account.
- For Single Pay transactions, keep the transaction ID generated at the end of the purchase process.
- For Subscriptions, keep the transaction ID, the merchant subscription ID, and the consumer ID.
The Merchant application can use the same callback listener to receive notifications. However, the notification handler should have the mechanism to process the notification payload instead of just the notificationId. You should also remove any calls to the GetNotification and DeleteNotification methods, as they are no longer supported.
You will need to set up IP Filtering to allow the API Platform to reach your notification URL. Please refer to the Notification guide for the IPs which must be configured for IP filtering.
The important parameter for correlation is the vendorPurchaseIdentifier which is nothing but the MerchantTransactionId which you had passed on the Payment API method Call. This can be used for correlating the notification with the corresponding transaction.
The Payment API Platform has been revamped in this release, keeping the API methods and signatures the same, but please note the following changes:
- The Notification mechanism: The Get Notification and Delete Notification methods are no longer supported. Instead the notification payload will be sent directly to the notification callback URL in XML format. The new notification callback operation is explained in Resources and further details are explained in the “Payment Notifications Guide”. The GetNotification and DeleteNotification methods are removed and no longer required to be called.
- GetTransactionStatus: After this release, GetTransactionStatus cannot be called for Refund Transactions to retrieve the transaction ID and transaction authentication code.
- Merchant Level Risk Limits, such as Global Limits, Merchant Limit profiles, Merchant Custom Limits, no longer apply.
- Merchant Email notifications are reduced to only account setup events and there will not be email notifications for payment transaction activity.
- ContentCategory, Description, and TransactionType fields, in the response of GetTransactionStatus and GetSubscriptionStatus, will be empty.
- Response to GetSubscriptionDetails will have Current Start Date, Current End Date, and Creation Date empty.
AT&T requires that the customer grant consent for all payment transactions. The customer must acknowledge that they are buying a particular product, for a specific amount (taxes not included), sold by a particular application and merchant.
To make a purchase, customers must authenticate themselves (via our OAuth 2.0-based process) by providing their AT&T Access ID / MSISDN and PIN.
Each purchase is signed by the AT&T Notary API to ensure the payload cannot be tampered with.
These fields need to be known by the Merchant Application based on the API call that was made for creating this subscription. Another way to know about these fields is through Reports.
The Payment API can provide a simple and safe process for enabling customers to purchase or subscribe to your app, which can potentially result in more sales for you. When you integrate the Payment API into your app, you get access to over 100 million AT&T subscribers, each of whom can place charges on their mobile invoice. This process does not involve long and hard-to-remember phone numbers to call and does not expose any credit card information.
These settings are used to differentiate between Payment Notifications related to apps in the Sandbox Realm versus Payment Notifications related to apps in the Production Realm, for a given AT&T Merchant account.
Yes. Please note the following differences:
- For a Full Access account in the Sandbox realm; the purchases range from $0.01 through $24.99. For a Full Access account in the Production realm; the purchases range from $0.99 through $99.
- For a Full Access account in the Sandbox realm; 100% of the revenue is retained by AT&T. For a Full Access account in the Production realm; the revenue share is split 30/70 with AT&T retaining 30%.
- The service-level agreement (SLA), and the allowed transactions per second (TPS) differ between the two realms. For more information about these differences, please contact the Developer support team at firstname.lastname@example.org.