cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Customer Refund with paymentProfileId and transId only?

The documentation on how to issue refunds against Accept Customer payment profile transactions is either incorrect or incomplete:

 

From https://developer.authorize.net/api/reference/features/customer_profiles.html#Charging_Customer_Prof... 

 

f you submit a refund against a previous customer profile transaction, we recommend that you:

Include customerProfileId, customerPaymentProfileId, and transId.

Given that the Authorize.net API is very picky about the order of fields, it would be great if somebody could document the API request structure with a customerProfileId and customerPaymentProfileId. If you try to do it the same way as charging a customer profile, the schema complains that profile is not valid:

 

{
	"createTransactionRequest": {
		"merchantAuthentication": {
			"name": "myloginid",
			"transactionKey": "mytransactionkey"
		},
		"transactionRequest": {
			"transactionType": "refundTransaction",
			"amount": "97.85",
			"refTransId": "123456",
			"profile": {
				"customerProfileId": "12345678",
				"paymentProfile": {
					"paymentProfileId": "23456789"
				}
			},
			"order": {
				"invoiceNumber": "1P4-1",
				"description": "(REFUND) A Test Invoice"
			},
			"customerIP": "172.18.0.1",
			"transactionSettings": {
				"setting": [{
					"settingName": "emailCustomer",
					"settingValue": false
				}, {
					"settingName": "duplicateWindow",
					"settingValue": 5
				}]
			}
		}
	}
}

If you take the documentation page literally and just add the fields customerProfileId and customerPaymentProfileId (confusingly named and structured differnetly than they are when charging the customer profile), you get the same error:

 

The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'customerProfileId' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'splitTenderId, order, lineItems, tax, duty, shipping, taxExempt, poNumber, customer, billTo, shipTo, customerIP, cardholderAuthentication, retail, employeeId, transactionSettings, userFields, surcharge, merchantDescriptor, subMerchant, tip, processingOptions, subsequentAuthInformation, otherTax, shipFrom' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'.

None of those allowed fields have anything to do with customer profiles.

 

This suggests one of two things:

 

1. There is a separate endpoint or API function besides createTransactionRequest for refunding transactions that were charged to customer profiles, or:

2. The documentation on the Accept Customer page is incorrect and you have to submit the last 4 digits of the card without the payment profile.

 

I did find this thread: 

 

https://community.developer.authorize.net/t5/Integration-and-Testing/How-to-submit-refund-using-cust...

 

But he's using the SDK and it's not clear how that request is structured under the hood.

 

May I add that reading the field lists in the documentation is an extremely frustrating experience, having to trace back to 'okay, how many dots was the parent element' -- I appreciate that a lot of people just use SDKs and don't care about this stuff, but we are implementing the API in our software directly and expected both better formatting and more consistency in documentation than what we have found so far.

inLeague
Contributor
1 ACCEPTED SOLUTION

Accepted Solutions

Figured this out through trial and error, if anybody else runs into it. The documentation should be updated because while you do include transId, you do it as refTransId and in a very particular location.

 

An example in the docs wouldn't hurt, either. We assumed by going with a well-estbalished company like Authorize.net that we wouldn't have to spend a weekend afternoon trying different permutations in our request to see which one happened to succeed.

 

{
	"createTransactionRequest": {
		"merchantAuthentication": {
			"name": "myloginid",
			"transactionKey": "mytransactionkey"
		},
		"transactionRequest": {
			"transactionType": "refundTransaction",
			"amount": "97.85",
			"profile": {
				"customerProfileId": "1234567",
				"paymentProfile": {
					"paymentProfileId": "3456789"
				}
			},
			"refTransId": "60126862687",
			"order": {
				"invoiceNumber": "1P4-1",
				"description": "(REFUND) A Test Invoice"
			},
			"customerIP": "172.18.0.1",
			"transactionSettings": {
				"setting": [{
					"settingName": "emailCustomer",
					"settingValue": false
				}, {
					"settingName": "duplicateWindow",
					"settingValue": 5
				}]
			}
		}
	}
}

 

View solution in original post

inLeague
Contributor
1 REPLY 1

Figured this out through trial and error, if anybody else runs into it. The documentation should be updated because while you do include transId, you do it as refTransId and in a very particular location.

 

An example in the docs wouldn't hurt, either. We assumed by going with a well-estbalished company like Authorize.net that we wouldn't have to spend a weekend afternoon trying different permutations in our request to see which one happened to succeed.

 

{
	"createTransactionRequest": {
		"merchantAuthentication": {
			"name": "myloginid",
			"transactionKey": "mytransactionkey"
		},
		"transactionRequest": {
			"transactionType": "refundTransaction",
			"amount": "97.85",
			"profile": {
				"customerProfileId": "1234567",
				"paymentProfile": {
					"paymentProfileId": "3456789"
				}
			},
			"refTransId": "60126862687",
			"order": {
				"invoiceNumber": "1P4-1",
				"description": "(REFUND) A Test Invoice"
			},
			"customerIP": "172.18.0.1",
			"transactionSettings": {
				"setting": [{
					"settingName": "emailCustomer",
					"settingValue": false
				}, {
					"settingName": "duplicateWindow",
					"settingValue": 5
				}]
			}
		}
	}
}

 

inLeague
Contributor