cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Charge a Credit Card - Shipping Name Length?

Hello,

 

I'm looking through the API Reference at the Charge a Credit Card API Method.  I don't see where it specifies the maximum length for these fields:

  • Tax
    • Name
    • Description
  • Shipping
    • Name
    • Description
  • Duty
    • Name
    • Description

What is the max length of the "Name" and "Description" fields above?  I tried to search the forums and various PDFs to find the answer, but I don't see it.

 

Also, is there an XSD available so I can validate my XML prior to POST?

 

Thank you!

dnsBuffaloNY
Contributor
2 ACCEPTED SOLUTIONS

Accepted Solutions

Hi @dnsBuffaloNY,

 

We'll try to get more specific formatting in future revs of the API Reference Guide. In the meantime, we do have an XSD. We actually hide it in plain sight right in the XML request itself.

 

For example in this request,

<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>API_LOGIN_ID</name>
    <transactionKey>API_TRANSACTION_KEY</transactionKey>
  </merchantAuthentication>
  <refId>123456</refId>
  <transactionRequest>
    <transactionType>authCaptureTransaction</transactionType>
    <amount>5</amount>
    <payment>
      <creditCard>
        <cardNumber>5424000000000015</cardNumber>
        <expirationDate>1220</expirationDate>
        <cardCode>999</cardCode>
      </creditCard>
    </payment>
  </transactionRequest>
</createTransactionRequest>

 

We reference the XSD using the AnetApi identifier as a standin for the base URL. If you expand that out to the full URL, you'd get https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd for the sandbox system (or its cousin, https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd for the live system).

 

 Hitting either of those directly will give you an XSD to validate against.

 

In the case of "tax" or "duty" or "shipping", they are all instances of "extendedAmountType", so they'll have the same constraints.

 

The relevant section from the XSD:

<xs:complexType name="extendedAmountType">
  <xs:sequence>
    <xs:element name="amount">
      <xs:simpleType>
        <xs:restriction base="xs:decimal">
          <xs:minInclusive value="0.00"/>
          <xs:fractionDigits value="4"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
    <xs:element name="name" minOccurs="0">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:maxLength value="31"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
    <xs:element name="description" minOccurs="0">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:maxLength value="255"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
  </xs:sequence>
</xs:complexType>

 So, the amount must be numerical with up to four decimal places, and must be greater than 0. No upper bounds.

 

Name is a string of length 31

Description is a string of length 255

 

Hope that helps!

View solution in original post

Aaron
All Star

Note: these are just the XSD limitations. Processors might have their own limitations that are more strict than these. For example, sending an amount in one of these fields with more than two digits in the decimal will likely cause an error with all processors. Basically, unless you're sending a transaction in a currency that uses more than two, and you're hooked up with a processor that you know supports that currency, stick to two digit decimals.

View solution in original post

2 REPLIES 2

Hi @dnsBuffaloNY,

 

We'll try to get more specific formatting in future revs of the API Reference Guide. In the meantime, we do have an XSD. We actually hide it in plain sight right in the XML request itself.

 

For example in this request,

<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name>API_LOGIN_ID</name>
    <transactionKey>API_TRANSACTION_KEY</transactionKey>
  </merchantAuthentication>
  <refId>123456</refId>
  <transactionRequest>
    <transactionType>authCaptureTransaction</transactionType>
    <amount>5</amount>
    <payment>
      <creditCard>
        <cardNumber>5424000000000015</cardNumber>
        <expirationDate>1220</expirationDate>
        <cardCode>999</cardCode>
      </creditCard>
    </payment>
  </transactionRequest>
</createTransactionRequest>

 

We reference the XSD using the AnetApi identifier as a standin for the base URL. If you expand that out to the full URL, you'd get https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd for the sandbox system (or its cousin, https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd for the live system).

 

 Hitting either of those directly will give you an XSD to validate against.

 

In the case of "tax" or "duty" or "shipping", they are all instances of "extendedAmountType", so they'll have the same constraints.

 

The relevant section from the XSD:

<xs:complexType name="extendedAmountType">
  <xs:sequence>
    <xs:element name="amount">
      <xs:simpleType>
        <xs:restriction base="xs:decimal">
          <xs:minInclusive value="0.00"/>
          <xs:fractionDigits value="4"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
    <xs:element name="name" minOccurs="0">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:maxLength value="31"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
    <xs:element name="description" minOccurs="0">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:maxLength value="255"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:element>
  </xs:sequence>
</xs:complexType>

 So, the amount must be numerical with up to four decimal places, and must be greater than 0. No upper bounds.

 

Name is a string of length 31

Description is a string of length 255

 

Hope that helps!

Aaron
All Star

Note: these are just the XSD limitations. Processors might have their own limitations that are more strict than these. For example, sending an amount in one of these fields with more than two digits in the decimal will likely cause an error with all processors. Basically, unless you're sending a transaction in a currency that uses more than two, and you're hooked up with a processor that you know supports that currency, stick to two digit decimals.