2026년 11월 5일 목요일

입금 확인 뒤 또 시작되는 월말 작업: 에이픽 현금영수증 API를 주문 기록에 연결하기

에이픽 API 홍보 · 가상 업무 시나리오

반복 업무를 연동하는 방법을 설명하는 글입니다. 실제 고객 사례나 성능 실측이 아니며, API를 실행하거나 실제 문서를 발급하지 않았습니다. 공식 문서는 2026-11-05 확인했습니다.

입금 확인은 끝났는데 현금영수증은 아직 밀려 있다면

소규모 예약 서비스의 월말을 가정합니다. 입금 확인 목록과 현금영수증 요청 목록이 서로 다른 파일에 있습니다. 담당자는 주문번호를 찾고, 금액을 다시 적고, 발급 완료 표시를 남깁니다. 야근을 만드는 것은 복잡한 계산보다 같은 내용을 여러 화면에 입력하는 과정입니다.

연동의 출발점은 거래 기록입니다. 실제로 입금이 확인되고 발급 요건을 충족한 거래를 담당자가 확인하면, 서버가 해당 거래의 입력값으로 에이픽 발급 절차를 진행하고 결과를 주문에 연결하도록 설계합니다.

에이픽 공개 홈페이지. 당시 메뉴와 상품 안내를 보여주는 화면입니다.
에이픽 공개 홈페이지. 당시 메뉴와 상품 안내를 보여주는 화면입니다. 2026-10-28 보관 화면, 2026-11-05 내용 재확인. 아래 발급 결과와는 별개인 공통 시작 안내입니다.

자동화 전에 발급 대상과 인증 방식을 확정하기

발급 대상 거래, 발급수단번호, 금액, 과세 구분과 용도를 먼저 검토해야 합니다. 취소되거나 아직 입금되지 않은 주문을 발급 대상으로 섞지 않습니다. 소득공제와 지출증빙 구분도 고객의 요청과 거래 사실에 맞춰 확인합니다.

이 글은 개인사업자의 간편인증 흐름을 설명합니다. 법인은 공동인증서가 필요하며 이 예시를 그대로 적용하지 않습니다. 본인 승인·사업자 인증 등 필요한 절차를 유지해야 합니다. 실제 현금영수증을 만드는 API이므로 연습용 거래를 임의 발행해서는 안 됩니다.

빈 회원가입 양식. 개인정보 입력이나 가입 실행 결과가 아닙니다.
빈 회원가입 양식. 개인정보 입력이나 가입 실행 결과가 아닙니다. 2026-10-28 보관 화면, 2026-11-05 내용 재확인. 아래 발급 결과와는 별개인 공통 시작 안내입니다.

주문 시스템의 서버에 연결하기

apick.app 계정을 준비하고 공식 개발가이드의 현금영수증 상품을 확인합니다. 인증키는 서버 환경변수로 읽습니다. 고객 연락처와 발급수단번호는 공개 로그에서 제외하고 필요한 범위에서만 처리합니다.

주문별로 발급 요청 상태를 남기고, 같은 거래를 재전송할 때 쓸 idempotency_key를 관리합니다. 네트워크 응답이 늦다는 이유만으로 새 키로 발급을 반복하지 않습니다. 먼저 이전 요청 결과를 확인하는 흐름이 필요합니다.

공통 개발가이드의 서버 환경변수 준비 화면. 실제 인증키 값은 표시하지 않습니다.
공통 개발가이드의 서버 환경변수 준비 화면. 실제 인증키 값은 표시하지 않습니다. 2026-10-28 보관 화면, 2026-11-05 내용 재확인. 아래 발급 결과와는 별개인 공통 시작 안내입니다.

발급 요청 cURL 구조

아래는 공식 필드에 맞춘 정적 설명용 예시입니다. 금액과 식별정보는 환경변수 표식이며, 실제 요청은 실행하지 않았습니다. purpose는 0 소득공제 또는 1 지출증빙, transaction_type은 01 과세·02 면세·03 간이 중 거래에 맞는 값을 확인해 넣습니다.

# 공식 명세 기반 설명용 예시. 실제 호출하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/req_cash_receipt_issue' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string "name=${APICK_NAME}" \
  --form-string "birthDate=${APICK_BIRTH_DATE}" \
  --form-string "phone=${APICK_PHONE}" \
  --form-string "authProvider=${APICK_AUTH_PROVIDER}" \
  --form-string "receipt_no=${APICK_RECEIPT_NO}" \
  --form-string "amount=${APICK_AMOUNT}" \
  --form-string "idempotency_key=${APICK_IDEMPOTENCY_KEY}" \
  --form-string "purpose=${APICK_PURPOSE}" \
  --form-string "transaction_type=${APICK_TRANSACTION_TYPE}"

인증 요청에서 받은 transactionId를 보관하고, 본인 승인 이후 아래 API에서 결과를 확인합니다. 결과가 준비되지 않았다면 완료 처리하지 않습니다.

# 공식 명세 기반 설명용 예시. 실제 호출하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/get_cash_receipt_issue' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string "transactionId=${APICK_TRANSACTION_ID}"
공통 연결 확인용 /rest/info 정적 cURL 예시. 이 글의 발급 API를 실행한 화면이 아닙니다.
공통 연결 확인용 /rest/info 정적 cURL 예시. 이 글의 발급 API를 실행한 화면이 아닙니다. 2026-10-28 보관 화면, 2026-11-05 내용 재확인. 아래 발급 결과와는 별개인 공통 시작 안내입니다.

승인번호를 주문과 연결하는 응답 처리

다음은 공식 정적 예시의 결과 부분입니다. 승인번호·거래일시는 비공개 처리했고 금액은 공식 예시 값을 유지했습니다. 실제 거래나 실제 발급을 증명하는 자료가 아닙니다.

{
  "data": {
    "result": {
      "cashReceiptIssue": {
        "승인번호": "[비공개]",
        "거래일시": "[비공개]",
        "합계금액": 1000,
        "공급가액": 910,
        "부가세": 90,
        "용도구분": "소득공제"
      }
    }
  }
}

응답의 합계금액을 원래 주문과 대조하고 정상 결과인지 확인한 뒤 발급 완료 상태로 바꿉니다. 공급가액·부가세 예시를 모든 거래의 계산식으로 복사하지 말고, 과세 구분과 실제 반환값을 검토합니다. 승인번호는 내부 대조용으로 제한해 보관하고 외부 콘텐츠에 노출하지 않습니다.

비용과 실패 처리를 놓치지 않기

문서상 인증 요청은 20P, 첫 결과 제공은 100P입니다. 사용 가능한 포인트 재원과 결제 이력 관련 이용 조건은 운영 전에 최신 정책으로 확인해야 합니다. 인증 요청 비용과 결과 비용은 별개이므로 실패했을 때 항상 전체 비용이 0이라고 가정하지 않습니다.

HTTP 상태뿐 아니라 업무 상태·오류·resultAvailable을 확인합니다. 승인 거절·만료는 담당자가 확인할 목록으로 보내고, 준비 중에는 같은 transactionId로 기다립니다. 부분 결과나 금액 불일치가 있으면 바로 완료로 바꾸지 않습니다.

월말의 복사·붙여넣기를 줄이는 운영

연동 후 관리 화면에는 발급 대기, 승인 대기, 완료, 확인 필요를 나눠 보여줄 수 있습니다. 담당자는 모든 거래를 다시 입력하기보다 누락과 예외를 점검하게 됩니다. 줄어든 작업시간은 실제 운영에서 측정하고, 예시만으로 “몇 분에 전체 완료”라는 성과를 단정하지 않습니다.

에이픽 현금영수증 API를 거래 기록과 연결해, 발급 결과를 다시 옮겨 적는 단계부터 줄여 보세요.

공식 문서

댓글 없음:

댓글 쓰기