API Page Guide

This is a sample API Call description page that provides guidance about formatting content. This applies only to pages in the multi-column format.

Emphasis

Certain items are emphasized in order to bring the readers eye to the item and also to differentiate terms. Objects and parameters are identified by highlighting them in a specific manner. Values (or the names of values) that form part of a name/value (or parameter/value) pair are emphasized in a manner different than that for the associated object or parameter. In a table or bullet list, the need for this is not always obvious, however this becomes a critical comprehensibility issue in paragraph text.

Version: v2 2016-06-22

Endpoint

https://wepayaip.com/foo

Tables

State Table

State One Lorem ipsum dolor sit amet, consectetur adipiscing elit.
State Two Proin eleifend eleifend ipsum, tristique tristique tortor ornare eget.
State Three ellentesque faucibus auctor lorem, non hendrerit tellus imperdiet at.

Argument and Response Tables

</tbody> </table>
Response Type Description
account_id Integer (64 bits) The unique ID of the account.
name String (255 chars) The name of the account.
state String (255 chars) The state of the account.

Possible values:
  • action_required
  • active
  • disabled
  • deleted
</tr>
disabled_reasons Array Array of strings explaining all reasons for why an account was disabled. It will be empty if the account is enabled. Possible values are:

  • fraudM: WePay has determined that fraudulent activity is occuring and is perpetrated by the account administrator (not a fraudulent transaction by a payer), or the account is being administered for fraudulent purposes. The account can be reinstated if an appeal has been made and the subsequent investigation reveals that any fraud found is not a result of fraudulent activities on the part of the account owner or administrator.

  • high_risk_chargeback: Based on an account history of excessive chargeback activity or a determination by WePay that the tuype of business is at high risk of excessive chargebacks. There is no remediation for this type of disablement.

  • reported_user: The platform has reported that they closed the merchant account. The account administrator must resolve issues with the platform before WePay can reinstate the account.

  • tos_violation: Occurs when the TOS agreement has been violated by the merchant. See our Terms of Service section 7 for more information.

  • country_not_supported: Occurs when the merchant is not operating in one of WePay's supported countries or is accepting payment in a currency other than that of the country where they are registered.

    Example: The merchant is a British citizen or organization and the account is setup to accept payment in USD or CAD. The merchant must re-establish the account using the correct currency.

  • closed_for_loss: Occurs when the account balance becomes negative and remains so for a period of 30 days. Remediation of this state is on a case-by-case basis following review by the WePay Risk Team.

  • no_settlement_path: Occurs when more than 30 days have elapsed after the merchant accepts their first payment and no settlement path has been established. This is remediated by adding a settlement method (i.e. a bank account) and completing the KYC process.

supported_card_types Array Array of supported card type strings for this account.

Possible card types are:
  • visa
  • mastercard
  • american_express
  • discover
  • jcb
  • diners_club

Example


{
    "parameter1": "something here",
    "parameter2": 123234,
    "parameterSrruct": {
        "fieldOne": "foo",
        "fieldTwo": "bar",
        "numbers": 123345
    }
}

Reusable Code Block Example: Part 1

This section illustrates how to place a duplicate json block using a single source.

Steps to create a reusable JSON code block:

  1. Create the code block in the usual manner using the triple-tic markup and specify json as the identifier.
  2. Enclose the entire codeblock and triple-tic text in a uniquely named capture tag .
  3. In the include module at the bottom of the section, reference the uniquely named capture (e.g. right=foo). Do this in both the first occurance, and any subsequent occurance of the code block. The following two sections are an illustration of this technique.

Arguments

Parameter Required Type Description
first_name Yes String (255 chars) The user's first name
middle_init No String (1 char) User's middle initial
last_name Yes String (255 chars) The user's last name.

Example

{
    "first_name": "Harry",
    "middle_init": "J",
    "last_name": "Potter"
}

Response

Response Type Description
magic_word String (255 chars) The user's magic word.

Example

{
    "magic_word": "hogwarts"
}

Reusable Code Block Example: Part 2

This call gets Harry’s info. It’s response uses the captured code block from Part 1. Use the value returned in magic_word the call above.

Parameter Required Type Description
magic_word Yes String (255 chars) The magic word to make this happen.

Example


{
    "magic_word": "hogwarts"
}

Response

Response Type Description
first_name String (255 chars) The user's first namme.
middle_init String (1& chars) The user's middle initial.
last_name String (255 chars) The user's last name.

Example

{
    "first_name": "Harry",
    "middle_init": "J",
    "last_name": "Potter"
}
Response Type Description
delivery_type String Delivery type for checkout.

Possible values:

  • none
  • fully_delivered
  • point_of_sale
  • shipping
  • donation
  • subscription
  • partial_prepayment
  • full_prepayment

Response Type Description
delivery_type String Delivery type for checkout.

Possible values: none, fully_delivered, point_of_sale, shipping, donation, subscription, partial_prepayment, full_prepayment.