Payments

Introduction

The Payments API system allows an API consumer to safely store and retrieve payment methods (credit cards, gift cards, etc.) to/from a secure, encrypted system.

How It Works

The system works off by only passing token values where possible The API consumer would never use a full, unencrypted credit card number, thus limiting the amount of information that could potentially be stolen should someone attempt to do so.

For example, to use the POST Connect/{subscriberId}/PaymentMethods/CreditCard endpoint, you would build and pass a CreditCardPaymentAddRequest object to it, and receive a token (GUID) in return. This token is what’s used to reference and use the card later.

How To Use Payments

  • Storing a Payment

    To store a payment, you will pass a CreditCardInfo object into the POST Connect/{subscriberId}/PaymentMethods/CreditCard path. If everything is successful, you’ll receive the stored PaymentMethod with a token referencing the payment in return.

    If temporarily storing the credit card, set the TemporarilyStore boolean of the CreditCardPaymentAddRequest object to true. You will still receive the stored PaymentMethod with a token referencing the payment in return, but this is the only time you will receive this payment method as it is only to be used during the session. It will not be returned when attempting to retrieve stored payments. Once the user logs out, the payment will be unavailable to use again.

    Payments will be validated on several criteria when stored:

    • The user sending the request, must have permission to modify secure payment methods.
    • The credit card number must match the submitted card type (Must start with 4 for a Visa card, 2 or 5 for MasterCard / Maestro UK, etc.)
    • The credit card number must be valid.
    • The credit card must not be expired.
    • The subscriber must accept the credit card type.
    • The subscriber address requirements will be checked (Postal code and/or address required).
    • If the payment is being stored permanently (i.e., not a temporary stored payment method), it cannot already exist at the subscriber. That is, a credit card with the same card number, card type (Visa, MasterCard, etc.), and expiration date cannot already have been stored at the subscriber.

  • Retrieving Stored Payments

    To retrieve stored payment methods that belong to a Connect user use the following endpoint: GET Connect/PaymentMethods/Stored

    Note: Balances returned in GiftCards from this endpoint are their original amounts and not reflective of their actual balance.

  • Retrieving Shopping Payments

    To find payments that are usable for shopping for a connect user. Use the following endpoint. GET Connect/{subscriberId}/PaymentMethods/Shopping

    There is also the option of getting a specific gift card based on the ID by using GET-Connect-subscriberId-PaymentMethods-GiftCard-externalId

  • Payments Configuration

    Configuration, rules, and general settings regarding payments are found at: GET Connect/{subscriberId}/PaymentMethods/Configuration

Current Limitations

  • 4/21/2015

    • Can only store credit cards as payments.
    • Exchange cards must start with "4036".
    • When persistently storing Credit Cards, the CountryCode will not be taken into account due to system limitations when merging credit card storage.

Miscellaneous

PaymentMethod

The PaymentMethod object outlines details for a specific payment method (Credit Card, Cash, Bank Account, Gift Card, etc.). This includes, but is not limited to, the Payment Method Type, rules, options, and any details related to the payment method.

DateTimes

Note: All Dates and Times for subscriber based endpoints are returned/expected without a time zone offset. The raw date and times are local to the subscriber's time zone.